File monitor stops with FileSystemException when copying a large directory structure into the watched folder

If I copy a large directory structure (the unzipped jmeter package as example) into a watched folder, then the FileMonitor stops with a java.nio.file.FileSystemException:

java.nio.file.FileSystemException: ...: The process cannot access the file because it is being used by another process.

        at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
        at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
        at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
        at sun.nio.fs.WindowsDirectoryStream.<init>(Unknown Source)
        at sun.nio.fs.WindowsFileSystemProvider.newDirectoryStream(Unknown Source)
        at java.nio.file.Files.newDirectoryStream(Unknown Source)
        at java.nio.file.FileTreeWalker.visit(Unknown Source)
        at java.nio.file.FileTreeWalker.walk(Unknown Source)
        at java.nio.file.FileTreeIterator.<init>(Unknown Source)
        at java.nio.file.Files.walk(Unknown Source)

I’ve tested this on Windows 7 with the following code:

val watcher = new FileMonitor(directory, recursive = true) {
  override def onEvent(eventType: WatchEvent.Kind[Path], file: File, count: Int) = eventType match {
    case EventType.ENTRY_CREATE => logger.info(s"$file got created")
    case EventType.ENTRY_MODIFY => logger.info(s"$file got modified $count")
    case EventType.ENTRY_DELETE => logger.info(s"$file got deleted")
  }
}
watcher.start()(context.system.dispatcher)

[gmethvin]

@pathikrit Yes, I’m already using it here: https://github.com/gmethvin/directory-watcher/#better-files-integration-scala. I think the File.Monitor interface is a good integration point for other libraries.

[gmethvin]

@pathikrit The FILE_TREE part of it could be ported potentially but I’m not sure if you’re comfortable with the JNA dependency for the OS X implementation. Another option is to have a way to plug in alternate implementations for the file monitor in better-files, so I could create a library that provides the custom implementation.

Regarding this bug, the real issue is that there’s generally going to be a delay between the time a new directory is created and when we can register a listener on it. We’ll miss any events that happen during the time we weren’t listening. I don’t think there’s a foolproof way to eliminate that race condition without hooking into low-level OS functionality.