Support Trash folders on alternate drives/partitions

[rushsteve1]

This is a follow-up to #1

Currently trash-d will copy a file into the user's home trash folder when trashing a file on a different drive/partition. This isn't great from a speed and space perspective, nor from a compatibility one (though it is spec-compliant).

A future version of trash-d could enumerate /proc/mounts (or some other facility if D has one) to find out what device it is on, then use that information to find and use a .Trash folder on that device.

However this also poses a number of UX issues. trash --list would have to find and list the trash on every single device, trash --empty now has the potential for considerably more unintended damage. trash --del and trash --restore are now ambiguous if you have 2 files with the same name across different drives.

In addition to all this, it could substantially complicate trash-d's code since there would no longer be a single known trash directory. It could also possibly tie it even more tightly to Linux, and I would like to support the BSDs which would complicate things further.

This issue is for discussing the future of this feature, and in general determining whether or not it is worth doing. So questions, comments, and suggestions are welcome!

[ibara]

In addition to all this, it could substantially complicate trash-d's code since there would no longer be a single known trash directory. It could also possibly tie it even more tightly to Linux, and I would like to support the BSDs which would complicate things further.

Only OpenBSD lacks procfs, if you are concerned about that. We'd probably take a version(OpenBSD): _don't do procfs_ and be fine with it. An interested person can always come around later and make multiple trash dirs work without procfs.

[CyberShadow]

A future version of trash-d could enumerate /proc/mounts (or some other facility if D has one) to find out what device it is on, then use that information to find and use a .Trash folder on that device.

I have a /proc/mounts parser here:
https://github.com/CyberShadow/ae/blob/d1978633a28b3ea0a0a33ea29b61ff45cc8623c5/sys/file.d#L1614-L1703

If you decide to write one yourself, make sure to unescape the paths.

A more portable alternative may be to walk up the directory hierarchy until st_dev changes.

realpath should be called before doing either.

[rushsteve1]

Only OpenBSD lacks procfs, if you are concerned about that. We'd probably take a version(OpenBSD): _don't do procfs_ and be fine with it. An interested person can always come around later and make multiple trash dirs work without procfs.

The immediate problem with this approach would be introducing different behaviors on different OSes, and the separate code paths to go with. And I feel like doing this even for one OS opens the can of worms. and suddenly there's justification for platform-specific version flags everywhere. My whole intent in restricting it to POSIX/Freedesktop systems was to avoid the need for platform specific code.

---

I have a /proc/mounts parser here:
https://github.com/CyberShadow/ae/blob/d1978633a28b3ea0a0a33ea29b61ff45cc8623c5/sys/file.d#L1614-L1703

If you decide to write one yourself, make sure to unescape the paths.

Thanks for sharing this, could be very helpful!

A more portable alternative may be to walk up the directory hierarchy until st_dev changes.

This could be a very good way to work around parsing /proc/mounts in a way that would work on all POSIX systems. Though I can't think of a way to implement --list, --empty, or --restore using this, since they'd need to know the location of all trash folders and can't walk the tree backwards.

[rushsteve1]

Two possible workaround that I've come up with are:

• The ability to set the path to the trash directory via CLI option or environment variable.
• A CLI/envvar toggle that causes trash-d to walk up from the cwd looking for .Trash/ folders or device switches. This one is a bit trickier since it'd need to detect what partition $HOME is on, as well as fall back when necessary. It also isn't really good UX.

One or both of these could be a good stopgap at least.

[rushsteve1]

Closing this as being largely fixed in version 15 as part of #5