E-e-dant·Mar 28, 2026
Since there are comments below asking about benchmarks, others noting or expressing interest in other projects, I'll drop the one I made: https://github.com/e-dant/watcher (and also an ebpf experiment https://github.com/e-dant/bpf-fs-events)
There are benchmarks in there, and comparisons with all the other watchers out there I could find at the time I made it (see "Comparison with Similar Projects" at the very bottom of the readme).
It's a pretty long list. Tons of watchers out there with different design philosophies and shapes of problems they solve.
There are a lot of caveats to the filesystem monitoring APIs provided by kernels. Some projects (like facebook's watchman) take that as a kind of antagonism, and decide to fight back with layers and layers of fallbacks and distrust and rescans. That projects basically only makes sense as a
Read the rest
daemon.
Other programs and libraries try to take that complexity and tame it by being super-focused on one platform or providing a lot of configuration options.
Some provide debouncing logic. This particular feature comes up from time to time, I believe, both for practical reasons and because over-reported events from the kernel subsystems, especially for some arcane events like moving a file across mount points can trigger a flurry of hard-to-associate events for the same path.
If you want to avoid dealing with under-documented filesystem event subsystems, you can also just make your own with ebpf. Especially for security-oriented systems, you'll find that the only (nearly) perfectly accurate filesystem event subsystem you can make, is the one you make from the ground up.