Will

One case which I've found fanotify indispensable is when I need to watch an entire filesystem. Inotify and kqueue quickly run out of file descriptors. Fanotify doesn't (if watching paths,...

(Side question: How does notify-rs work around open file descriptor limits? I haven't found a good solution.)

I want to look more into 1 and 3 before I respond fully. However, here are my thoughts so far: For 1, my sense is that the events reported are...

2, 4 and 6 are accurate and intentional as-is. 5 is typical, but not necessarily correct. I will look into it. I have also seen plenty of "duplicate" modification events...

The interesting one -- Properly handling rename events -- Has been on my mind for many months now. I would appreciate your thoughts on how to handle them. One of...

Update on 1. Impression is that there's either (unlikely?) a bug in how the kernel reports modify events, or (more likely?) one of the syscalls used for opening the file...

Update on 3. > For 3, my sense is that we aren't watching the file, so the event isn't being reported to us. I will need to confirm that there...

I'll update the documentation as you suggest. I began work on rename-from/rename-to events. Currently, the implementation is storing a pointer to an associated event (within the existing event object). That...

I mentioned here: https://github.com/e-dant/watcher/issues/40#issuecomment-1784150862 That the linux adapters (on the `next` branch) should be mostly ready for use. They pass all of our existing tests, and I've been running them...

Your feedback is welcome about the current implementation, especially from an API perspective. Do you have more thoughts? Does the pointer to an "associated" event seem ergonomic from a user's...