jeffhostetler

4 yıl öncediscuss

I'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.

jeffhostetler

4 yıl öncediscuss

You 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

4 yıl öncediscuss

Thanks! And yes, I'll have a blog post on it. It is currently scheduled to appear on Wednesday on the GitHub blog.

The new `git fsmonitor--daemon` is mostly shared code but with custom "backends" for each platform hidden a small API. Yes, the Mac backend is built using FSEvents. The Windows backend uses ReadDirectoryChangesW. In both cases, the backend has a thread dedicated to receiving these events/notifications from the kernel, normalizing them, and queuing them for future client requests.

For sanity reasons, I had to draw the line at two platforms in the initial implementation.

There have been discussions about doing a Linux version using either inotify or fanotify, but that work has not started. (And $dayjob might keep me busy for a while on other things, so I'm open to others picking up that work.) It shouldn't be too hard given the API boundary and threading that I set up.

Likewise, for BSD.

comments