Hacker News Reader

Comment by mdaniel | Hacker News Reader

AGPLv3 https://github.com/Kharacternyk/klunok/blob/v1.0.2/LICENSE

but also

> Klunok uses the Linux kernel fanotify API, which as of now requires root privileges. Therefore, Klunok should be invoked, for example, with sudo

View on HN

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.

Reply on news.ycombinator.com