4 ms·
In my experience on Windows watching for file events, I’ve seen that it’s not very reliable. As the article notes, it’s possible that the operating system may d
by AnonHP 4y ago
In my experience on Windows watching for file events, I’ve seen that it’s not very reliable. As the article notes, it’s possible that the operating system may drop events. Nevertheless, this solution should help improve performance and reduce disk scans. If you have any other applications dependent on watching for file system events, enabling this may hinder those (again, this is based on my experience with Windows).
- japanuspus 4y agoMy main complaint with the Windows implementation is that it does not not play well with the lock-by-default policy of the NTFS filesystem. I deactivated the the filesystem watcher on Windows after the agent repeatedly locking files so that checkouts would fail.
- jeffhostetler 4y agoYou might give the new fsmonitor a try. It does not lock any files on the disk. It does have a single handle to the worktree root directory to listen for events. But even that is not exclusive. And it CWD's out of the tree during initialization, so it does not prevent you from deleting the worktree while it is running.
- jeffhostetler 4y agoI'm using ReadDirectoryChangesW() to read a filtered stream of events from the USN journal. I've not noticed any reliability problems. Technically, the kernel API can always drop events, but whether that is a kernel can't keep up problem or the daemon application not servicing the event stream fast enough doesn't really matter. The API does know if/when events were dropped. And the FSMonitor daemon guards against that and forces a "resync", so the "git status" client is advised to do a normal scan, so the output is correct.