It's a bundle in Ukrainian. You know, like in cartoons when a character walks away sadly with a bundle on a stick. I have a vivid childhood memory of a scene in Tom & Jerry where Tom does this. The idea of backed up files being in a digital bundle on a digital stick amused me enough to name the program like this.
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.
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.
13 comments
[ 0.15 ms ] story [ 893 ms ] threadhttps://en.wikipedia.org/wiki/Bindle
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
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.
I have an odd use case in mind:
1. Git handles intentional releases / commits
2. Klunok handles "timelapse" recording of development to avoid full screen capture
This would make it easier to re-play development and re-render code with zooming and styles as needed.