New BTRS project maybe worth looking at: BTRVIEW

[oshunluvr]

I'm attempting to troubleshoot another user who has this same problem but is on a fedora machine. Is the secure_path variable set in your /etc/sudoers file? It is commented out by default in the distribution I'm using and I can't think of why else the $PATH variable would be changing.

From my sudoers:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Not commented out and the path is there.

[jlittle]

btrview is not working well with snapper. It only shows the first and last elements of the path; in a subvolume list a snapper snapshot looks like, for example,

ID 2165 gen 59032 top level 275 path @hsnapshots/751/snapshot

In this example 751 is the important key used by snapper, showing in the snapper GUI.

btrview shows

├── @hsnapshots on: /home/.snapshots                           ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               ├── snapshot
│   ├── snapshot                                               └── snapshot​

[CopOnTheRun]

btrview is not working well with snapper. It only shows the first and last elements of the path; in a subvolume list a snapper snapshot looks like, for example,

ID 2165 gen 59032 top level 275 path @hsnapshots/751/snapshot

In this example 751 is the important key used by snapper, showing in the snapper GUI.

...

This is expected functionality as, by default, btrview only shows the subvolume names and not their full path. Additionally the tree is only constructed by subvolumes, not plain folders, so there wouldn't be a branch for the 751 folder, but there is a branch for the @hsnapshots subvolume and each @snapshot subvolume under it. If you want the full path to be shown you can pass the --property "btrfs Path". This feature isn't really documented that well because it's something that I'll likely modify soon.

[CopOnTheRun]

From my sudoers:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Not commented out and the path is there.

Ahh, thanks for that. I might add another note in the readme about this.

[jlittle]

If you want the full path to be shown you can pass the --property "btrfs Path".

Thank you, that works well.

I use the recommendation of the Arch wiki for snapper, #5.3.1, where ".snapshots" is a directory, with the snapshots subvolume, with a more useful name, is mounted on it in the fstab; otherwise if one boots to a snapshot snapper immediately stops silently because its snapshot subvolume ".snapshots" is not there. With --property "btrfs Path" that set up is shown nicely. My btrfs, snapper, and backups set up runs so smoothly that after a while I forget the details and extra names help.

Sorting the entries at each node of the tree would be good, perhaps with tree leaves before or after non-leaf nodes.

[CopOnTheRun]

...

Sorting the entries at each node of the tree would be good, perhaps with tree leaves before or after non-leaf nodes.

You can actually sort the entries by passing the --sort flag with one of "size,Creation time,Generation,Name" Since a lot of the features aren't documented in the README.md if you pass the --help flag to btrview it'll give a short explanation of the options. Just know these options are wont to change names/ be replaced in the future as I build out the program. Development has been a bit stale for the last week as it's been a busy one for me, but I plan to pick up the pace of things starting again next week!

[jlittle]

... If you want the full path to be shown you can pass the --property "btrfs Path". This feature isn't really documented that well because it's something that I'll likely modify soon.

Indeed. It is now --property Path.

Also, 0.7.1 needs the btrfsutil python module, installable with APT as python3-btrfsutil, at least in the Ubuntu repos.

[CopOnTheRun]

Indeed. It is now --property Path.

Also, 0.7.1 needs the btrfsutil python module, installable with APT as python3-btrfsutil, at least in the Ubuntu repos.

I didn't realize that btrfsutil was not included with btrfs-progs on ububtu, it's packaged in the same repository on arch, which is why the new install instructions include the --system-site-packages flag. I think I'll include the previous way of parsing subvolumes as well in the final version just in case the btrfsutil utility isn't available. It's not packaged on pypi so I can't pull it in that way, but it provides a better way of interfacing with btrfs than just calling the btrfs-progs command via python.

I'm getting closer to a 1.0 release now! Currently I'm writing a bunch of tests for it now that the api is getting more stable. I also have a couple more functionality updates on the horizon.

I'm not super active on this forum, so if you run into any issues, please feel free to open an issue on github! I'm also available as /u/copontherun on reddit as well if that works better! I'll definitely stop in here on occasion as well though!