logoalt Hacker News

e-dantyesterday at 9:29 PM0 repliesview on HN

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