What would be the reason they used fanotify instead of inotify? I used inotify before and didn't require special permissions. I want to suppose that inotify supports the klunok use case, but maybe I've overlooked something.

Also, I wonder what capabilities(7) would be sufficient, instead of requiring full-blown sudo powers. I saw a stackoverflow answer which suggested CAP_SYS_ADMIN, but they didn't provide a source for that claim.

Edit: Actually, the capabilities manpage does match fanotify_init to CAP_SYS_ADMIN. So, there's a source. Disappointing as it is.

inotify doesn't tell which process writes to a file, and Klunok is all about tracking only files edited by a human. Also, monitoring entire subtrees with inotify is painful and prone to race conditions.

Why only the files edited by a human? What about edge cases where changes made by a program, such as a linter or auto-formatter? Those aren't guaranteed to be integrated into an IDE.

That's all right if they are not integrated into an IDE. The typical scenario is: a file is edited by a human -> linter/formatters run -> 60 seconds delay -> the file is backed up. Therefore, debouncing has a handy side-effect of letting linters/formatters run before a version of the file is stored.

Shouldn't it be simpler to just specify just a directory (of a project for example) in which klunok tracks and saves modifications of all the files inside that said directory ? Anyway I'm not giving sudo rights just to replace git. And also depending on the number of files, the size of the files and the frequency of edit/save, it can become a mess. It may fit some needs but not mines. Interesting though.

Yes, the sudo bit is a drawback. The daemon drops privileges early, though. There is some work in the kernel space for rootless fanotify, which I look forward to. There is already some rootless fanotify API, but it requires holding onto a dangerous capability for the whole lifetime of the daemon, which appears worse than the current implementation to me.