GNOME Bugzilla – Bug 733970
Trashed items not shown in trash when trashed from btrfs subvolume
Last modified: 2018-09-21 17:42:49 UTC
I have noticed that when trashing items located on a btrfs subvolume using Nautilus 3.12.2, the trashed items do not show up when browsing the trash. In my case, my ~/Downloads is a btrfs subvolume, and I found that the trashed items are moved into ~/Downloads/.Trash-1000 (since moving files across btrfs subvolume boundaries implies copying, this behaviour is desired); however, the subvolume trash is not listed when browsing the trash location within Nautilus, and emptying the trash from Nautilus does not empty the subvolume trash.
-> gvfs Sounds like a bug in the gvfs trash backend.
The problem is that btrfs subvolumes do not show up as mounts in /proc/mounts so gvfs does not know that ~/Downloads/.Trash-1000 exists. I don't know if there's a real solution to this problem, but a workaround could be to explicitly mount the subvolume at ~/Downloads as one would with a regular fs so that it shows up in /proc/mounts and gvfs knows about it.
Created attachment 289519 [details] cat /proc/self/mountinfo (edited)
Created attachment 289520 [details] gvfs-mount -l
Can you elaborate? For me the subvolumes do show up in /proc/mounts . In my situation I have both home and downloads as subvolumes on the same btrfs fs. downloads is mounted under home in /home/<user>/downloads . The trash works fine for /home, but not for downloads. I looked at the code a bit and it seems to me gvfs uses udisks for the actual mount points listing/info, which in turn uses /proc/self/mountinfo. This mountinfo actually contains the subvolumes, but seems to use some btrfs specific hack in http://cgit.freedesktop.org/udisks/tree/src/udisksmountmonitor.c (line 447). Added output from 'cat /proc/self/mountinfo' and 'gvfs-mount -l'.
(In reply to comment #5) > Can you elaborate? For me the subvolumes do show up in /proc/mounts . > > In my situation I have both home and downloads as subvolumes on the same btrfs > fs. downloads is mounted under home in /home/<user>/downloads . The trash works > fine for /home, but not for downloads. In my case I have multiple subvolumes under my home, but they are not mounted from elsewhere. Only the container subvolume is explicitly mounted. I suppose that’s why they might not be listed as mounts (at least in this case). I guess btrfs might provide some sort of interface to enumerate subvolumes. There is «btrfs subvolume list», but at the moment this still seems to require root creds. OTOH, I wonder how gvfs winds up to create the .Trash in the right place after all. At least when files are trashed, gvfs seems to be aware exactly where the subvolumes are. Only when trashes are listed are the subvolume trashes missing.
(In reply to comment #6) > (In reply to comment #5) > > Can you elaborate? For me the subvolumes do show up in /proc/mounts . > > > > In my situation I have both home and downloads as subvolumes on the same btrfs > > fs. downloads is mounted under home in /home/<user>/downloads . The trash works > > fine for /home, but not for downloads. > > In my case I have multiple subvolumes under my home, but they are not mounted > from elsewhere. Only the container subvolume is explicitly mounted. I suppose > that’s why they might not be listed as mounts (at least in this case). Indeed... > > I guess btrfs might provide some sort of interface to enumerate subvolumes. > There is «btrfs subvolume list», but at the moment this still seems to require > root creds. > > OTOH, I wonder how gvfs winds up to create the .Trash in the right place > after all. At least when files are trashed, gvfs seems to be aware exactly > where the subvolumes are. Only when trashes are listed are the subvolume > trashes > missing. See https://git.gnome.org/browse/glib/tree/gio/glocalfile.c#n1647 It searches up the hierarchy for a trashdir with the device number.
(In reply to comment #5) > Can you elaborate? For me the subvolumes do show up in /proc/mounts . > > In my situation I have both home and downloads as subvolumes on the same btrfs > fs. downloads is mounted under home in /home/<user>/downloads . The trash works > fine for /home, but not for downloads. > > I looked at the code a bit and it seems to me gvfs uses udisks for the actual > mount points listing/info, which in turn uses /proc/self/mountinfo. This > mountinfo actually contains the subvolumes, but seems to use some btrfs > specific hack in > http://cgit.freedesktop.org/udisks/tree/src/udisksmountmonitor.c (line 447). > > Added output from 'cat /proc/self/mountinfo' and 'gvfs-mount -l'. I think it's not shown because it is an autofs mount which is considered a system internal mount (which are not considered for showing the trash). See https://git.gnome.org/browse/glib/tree/gio/gunixmounts.c#n300
See Bug 525779 for reasons, why autofs mounts aren't shown...
This happens also with bind mounts... See Comment 30 on GLib Bug 604015 which contains info what is needed to be done in order to fix the bug. Letting this bug open for now...
Just a note that this is also a problem for unmounted btrfs subvolumes, see: https://gitlab.gnome.org/GNOME/nautilus/issues/328
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/236.