Maybe adding a rate limiter on these write events would be a betterYou could always merge read/write events if you get too many of them. E.g. write [10,11] + write [11,12] => write [10,12]. But I never had event buffer overflows with my tests. And a buffer of a few kbytes per file system for fam won't be that bad, so I am not sure wether it is nessecary to do something as complicated as rate limiting or merging.
idea, live updates are usefull for the desktop. Also with a netlink
socket I think the overhead of many events would drop siginificantly.
Also a couple other items I think need to be on the list of features,You can monitor a whole tree with a single file descriptor. But you need at least one open fd per file system, so it would indeed be a problem when unmounting.
* Some way to not have an open file descriptor for each directory you
are monitoring. This causes so many problems when unmounting, and this
is really the most noticable problem for the user.
* Better event vocabulary, we should fire events for all VFS ops. II had this for a short time, but I threw it away since I wanted to concentrate on the event dispatch infrastructure first. It would not be a big problem to add this again.
think right now it is limited to delete,create,written to. It would be
good to tell the listener exactly what happened, moved,renamed, etc.