Bug#698640: gvfs-bin: gfvs-trash can not trash on fs that is bind mounted

[Simon McVittie]

On Sat, 05 Aug 2023 at 06:30:01 +0200, Christian Pernegger wrote:
> Funnily enough this used to work, in fact it still does work if you
> remove the checks. It'll find a location to trash to (in the root of
> the mount/subvolume) just fine; and if it doesn't it errors out
> elsewhere. The rationale for introducing them in the first place
> escapes me, to put it politely.

If you find yourself asking "why was this more obvious thing not done?"
then the answer is often "because there are cases where it doesn't work,
which might not apply to you, but do affect others".

The major reason not to allow trashing on a particular filesystem is
that it should not be possible to trash files unless it will also be
possible to undo the trash operation or empty the trash (possibly from
another process, or after a reboot or other state-losing operation).
Trashing the file is the easy part, being able to find it in the trash
directory afterwards is harder.

Being able to untrash or empty the trash requires file managers to be
able to enumerate and monitor all the possible trash directories on
the system. Otherwise, you can trash a file (moving it into a trash
directory), and then not have the ability to either untrash it again,
or delete it permanently: it'll continue to take up space, but you can't
get it back without knowing how to find it via a shell.

In GLib, sending files to trash is part of GLib itself, while retrieving
files from trash (either to untrash or to delete them permanently) is
part of gvfs, and both sides need to work together in a coordinated
way. If GLib can trash a file to a directory that gvfs won't find,
then we have a problem.

(It is entirely possible that some of the measures taken to avoid trashing
files into un-listable locations are broader than they strictly need to
be, because that's a less serious bug than the other way around.)

The freedesktop.org trash specification defines how to find the trash
directory in $HOME, and in a mounted drive (for example removable media),
so those are fine: it's straightforward to list mounted drives, and gvfs
can look for a possible trash directory inside each one.

However, the trash specification *doesn't* define how to find a trash
directory in a bind-mounted directory or in a btrfs subvolume. At first
glance a reasonable interpretation would be to treat them like mounted
drives, but that has design issues:

* It isn't possible for an unprivileged process to enumerate all of the
  btrfs subvolumes on the system (if they just exist inside a larger
  mounted directory, rather than being a separate mount point), which
  means that if each subvolume had its own trash directory, gvfs wouldn't
  be able to show you a merged list of trash for untrashing or permanent
  deletion: it can't know all the subvolumes that exist, and each one
  *might* have its own trash directory.

* Bind-mounts have the opposite problem: if a file is below a bind mount
  within the same filesystem (same device number), the usual Unix way
  to locate the root of a drive (go upwards through the hierarchy until
  you find a different device number) will not stop at the root of the
  bind-mount, because the device number remains the same across the
  mount point.

If you have a design in mind for how to do better, and you have checked
that design to make sure it will never result in files being trashed
to a directory that trash implementations like the one in gvfs cannot
subsequently list, then please contribute merge requests upstream. It is
likely that any change to how GLib's trash implementation works would
need to go into gvfs *before* it goes into GLib, because gvfs needs to
be able to find a trash directory before it becomes safe for GLib to
move files into it.

    smcv