All your snapshots, at your fingertips, enables NILFS2-inspired ZFS snapshots

Of course, ZFS loves that "most things are a file" for certain operations:

zfs send rpool/scratch@autosnap_2022-10-31_17:01:20_hourly | gzip > /srv/tmp/scratch.gz

However, I don't think the ZFS/btrfs/NILFS2 communities have wrapped their collective heads around the idea that snapshot datasets can be useful everywhere, especially at the file (read: not dataset) level.

This is the reason why Jim Salter's findoid was such an inspiration for httm (along with fzf, zsh key bindings, and rg). It was the first CLI tool I saw which made an attempt to deal with snapshots on a file level. One could always go looking for file versions, but findoid made an effort to consolidate useful snapshot information about a specific file.

httm attempts to take Jim's very broad idea to its logical conclusion. httm is an interactive, file-level Time Machine-like tool for ZFS/btrfs/NILFS2. See:

asciicast

Put simply -- httm aims to make all your snapshot data more easily accessible to all your UNIX tools, specifically, at the file level, because that's where UNIX tools live, so you can create new and interesting things for yourself.

So, what, in practice, does this mean? It means -- as a ZFS guy, one NILFS2 feature that always impressed me was how it seems to "take" continuous snapshots. In addition to checkpoints, one can stop a NILFS2 filesystem from garbage collecting, roll back to a point in time, and recover a file that was once there. And, this seems great, if you can take the performance hit of a log-structured file system (which is substantial). Just as I don't understand how people live without snapshots, I didn't want to live without "continuous" snapshots. With httm's help, my ZFS alternative to NILFS2 is simple -- instead of continuous snapshots, why don't we simply take a snapshot, if we need to, before we do something silly.

ounce (codename: "dimebag") is a wrapper script for httm which gives you no mental overhead, non-periodic dynamic snapshots.

When I type ounce nano /etc/samba/smb.conf (I actually alias $EDITOR='ounce --trace $EDITOR'), ounce knows that it's smart and I'm dumb, and it sees that I just edited /etc/samba/smb.conf a few short minutes ago, because it uses seccomp and eBPF to trace all the file open calls my $EDITOR makes, and uses httm to check whether I have any un-snapshot-ed changes. If I do, it takes a snapshot before I edit the file again.

Instead of an auto-save, you have auto-snapshot. Of course, we can confirm the snapshot was taken with httm:

➜ httm /etc/samba/smb.conf
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Tue Aug 09 16:46:14 2022  17.6 KiB  "/.zfs/snapshot/autosnap_2022-10-19_20:00:22_hourly/etc/samba/smb.conf"
Fri Oct 21 09:11:17 2022  17.6 KiB  "/.zfs/snapshot/snap_2022-10-21-09:11:18_ounceSnapFileMount/etc/samba/smb.conf"
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Fri Oct 21 09:11:25 2022  17.6 KiB  "/etc/samba/smb.conf"
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────

ounce is just one example of a new use enabled by snapshot data at your finger tips. I hope you'll find inspiration to use it to create something new and interesting for yourself too.