Problem: Existing snapshots are not being detected when commands like doas httm -i ~/ are used when snapshots are under /mnt/rpool/snapshots/home, where /mnt/rpool is the root.

Steps to reproduce:

1. Have the root mounted under a directory, such as /mnt/rpool with something like this in /etc/fstab (may have to restart computer instead of just using doas mount -a after adding to /etc/fstab)

UUID=...	/mnt/rpool	btrfs     	...,subvolid=5,subvol=/	0 0

2. Create a directory to hold the snapshots, i.e. doas mkdir -p /mnt/rpool/snapshots/home
3. Create a snapshot of the home subvolume (assuming /home is a subvolume), doas btrfs subvolume snapshot -r /home /mnt/rpool/snapshots/home/@home.test
4. Run doas httm -i ~/

Expected results: Snapshot under /mnt/rpool/snapshots/home/@home.test appears as an option.

Actual results: Snapshot doesn't appear as an option.

Additional information: The (trimmed down) results of doas btrfs subvolume list -s / are:

ID 3005 gen 594605 cgen 198847 top level 5 otime 2021-10-31 12:19:14 path @
ID 7309 gen 591271 cgen 466749 top level 5 otime 2022-04-03 05:50:56 path snapshots/home/@home.20220403T0550
ID 8040 gen 591271 cgen 521624 top level 5 otime 2022-05-01 00:00:01 path snapshots/home/@home.20220501T0000
ID 8041 gen 591271 cgen 521690 top level 5 otime 2022-05-01 00:32:41 path snapshots/root/@.20220501T0032
ID 8208 gen 594637 cgen 535944 top level 259 otime 2022-05-08 19:54:17 path @home/kody/.local/share/Steam
...
ID 9017 gen 592987 cgen 592986 top level 5 otime 2022-06-07 21:40:26 path snapshots/root/@.20220607T2140
ID 9018 gen 592988 cgen 592987 top level 5 otime 2022-06-07 21:40:26 path snapshots/root/@.20220607T2140_1
...
ID 9038 gen 594602 cgen 594602 top level 5 otime 2022-06-08 20:00:01 path snapshots/home/@home.20220608T2000

Ubuntu 22.04 - AMD Ryzen 9 5950X 32GB RAM

When running "httm -d -R ~" CPU spikes and PC becomes unresponsive.

installed from httm_0.17.0_amd64.deb

Love this utility, it's really neat! Unfortunately --preview doesn't seem to work? I just built 0.17.4 using a custom fork of nixpkgs, and running httm --preview -s looks like this:

Then after selecting a file that changed, this is the next screen:

As you can see, there's no diff shown. Could this be because of custom FZF settings? Other settings don't seem to influence the appearance of httm (I have a custom cursor for example), but maybe that's a potential source of bugs. I tried just --preview as well as custom commands (--preview='delta {snap_file} {live_file}' and --preview='diff {snap_file} {live_file}'), none seemed to work. Any idea why not?

PS: Maybe if no arguments are specified in --preview, assume that the command just takes arguments in diff order?

When attempting to build from source:

   Compiling httm v0.13.0 (/home/me/httm)
error[E0716]: temporary value dropped while borrowed
   --> src/utility.rs:286:26
    |
286 |     let mut out_locked = std::io::stdout().lock();
    |                          ^^^^^^^^^^^^^^^^^       - temporary value is freed at the end of this statement
    |                          |
    |                          creates a temporary which is freed while still in use
287 |     write!(out_locked, "{}", output_buf)?;
    |     ------------------------------------ borrow later used here
    |
    = note: consider using a `let` binding to create a longer lived value

For more information about this error, try `rustc --explain E0716`.
error: could not compile `httm` due to previous error
cargo-deb: build failed

Hi there, I just set up a clean bare metal machine with ZFS to try HTTM. Here was my install process:

zfs snapshot -r bootdev5@orig
pkg install git rust
export PATH=$PATH:/root/.cargo/bin
git clone https://github.com/kimono-koans/httm.git
cargo install --path ./httm/
[no errors]
zfs snapshot -r bootdev5@after-httm

And then I go: httm -I -R ~/ And it goes: Error: httm could not find any valid ZFS datasets on the system.

Did I miss a step?

The issue: ./httm: /lib/x86_64-linux-gnu/libm.so.6: version 'GLIBC_2.29' not found (required by ./httm)

Happens of officially supported debian/buster.

Is there any choice to compile it against musl instead of glibc or at least lower requirement to have only most recent version ? It would be also pretty useful if utility would be truly statically compiled to avoid any dependencies that allows to use it across all Linuxes regardless of distribution and versions

I tried using the provided .deb packages on an Ubuntu 20.04 server; neither the 0.13.0 nor 0.12.11 packages could be installed due to version conflict with libc.

dpkg: dependency problems prevent configuration of httm:
 httm depends on libc6 (>= 2.34); however:
  Version of libc6:amd64 on system is 2.31-0ubuntu9.9.

When built directly from the packaged source, 0.12.11 worked fine; the method I used was downloading the source from the 0.12.11 release, apt install cargo, then cargo deb followed by dpkg -i on the freshly built local package.

Reposted from r/btrfs:

...

When last I asked, I, perhaps too hastily, decided a port wasn't for me, because httm couldn't be made to easily work for all auto-snapshot programs (because the snapshot subvolumes/directories were never in the same place).

Now, I think searching for the most common subvolume mount points (.snapshot for Snapper, etc.) and/or letting the user set another directory via an environment variable (e.g., BTRFS_RELATIVE_SNAPSHOT_DIR) would be enough to cover most use btrfs use cases.

I'd like to ask:

1. Is this a sane approach?
2. Should (when do) I ever need to care about "@" subvolumes? That is -- if my PWD is /var/log, and I have a snapshot subvolume for /var/log, the location of .snapshots will generally always be at /var/log/.snapshots/?
3. What are the most common snapshot-ing schemes used by btrfs users besides snapper (.snapshots) and timeshift (timeshift-btrfs/snapshots)?
4. Is there anyone here, who keeps lots of snapshots (100s-1000s), who would be willing to test the software on their system?
5. Could some snapper/timeshift users post their detailed mount and btrfs-subvolume(8) information so that I'm sure what I'm doing comports with how btrfs is used in practice? Perhaps to a Github issue I open? I'd particularly be interested in anyone who backs up (send/receive) their root volumes locally to another volume/pool.
6. When you wish to view your snapshots read-only, are subvolumes automounted as needed or must you use some other process to mount?

A few simple changes:

• Combine the git clone and build steps into a single command
• Enable linker optimizations (https://doc.rust-lang.org/cargo/reference/profiles.html#lto)
• Automatically strip the release binary (reduces the size of the release binary)

My system is using zsys to do snapshots, which seem to happen when I install things with apt.

httm should provide some generalized documentation on how to create snapshots either manually or scheduled, so that there are more snapshots to choose from when using httm. Especially given the low disk cost of snapshots in zfs.

I ran httm -i on a ZFS dataset and searched for a deleted file. It could not find it. I also tried select mode with httm -s and it doesn't show the file. Findoid finds it in the snapshot. I installed using cargo and am running version 0.5.2