What does 'Klunok' mean?

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.

I can't comment on the Ukrainian word, but the "hobo sack" bundle-on-a-stick you're talking about is specifically called a "bindle":

https://en.wikipedia.org/wiki/Bindle

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

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.

Can this be used alongside a Git repo?

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.

Yes, Klunok can work alongside Git.

Nice idea! You would need fewer “backup commits” then :-)