After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 733970 - Trashed items not shown in trash when trashed from btrfs subvolume
Trashed items not shown in trash when trashed from btrfs subvolume
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: trash backend
1.20.x
Other Linux
: Normal normal
: ---
Assigned To: Allison Karlitskaya (desrt)
gvfs-maint
Depends on: 604015
Blocks:
 
 
Reported: 2014-07-30 11:45 UTC by Tobias Getzner
Modified: 2018-09-21 17:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
cat /proc/self/mountinfo (edited) (720 bytes, text/plain)
2014-10-28 13:16 UTC, Marinus Schraal
Details
gvfs-mount -l (409 bytes, text/plain)
2014-10-28 13:18 UTC, Marinus Schraal
Details

Description Tobias Getzner 2014-07-30 11:45:08 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.
Comment 1 Cosimo Cecchi 2014-09-13 06:09:16 UTC
-> gvfs

Sounds like a bug in the gvfs trash backend.
Comment 2 Ross Lagerwall 2014-09-16 17:33:18 UTC
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.
Comment 3 Marinus Schraal 2014-10-28 13:16:17 UTC
Created attachment 289519 [details]
cat /proc/self/mountinfo (edited)
Comment 4 Marinus Schraal 2014-10-28 13:18:22 UTC
Created attachment 289520 [details]
gvfs-mount -l
Comment 5 Marinus Schraal 2014-10-28 13:18:43 UTC
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'.
Comment 6 Tobias Getzner 2014-10-28 14:27:00 UTC
(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.
Comment 7 Ross Lagerwall 2014-10-28 17:08:24 UTC
(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.
Comment 8 Ross Lagerwall 2014-10-28 17:12:01 UTC
(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
Comment 9 Ondrej Holy 2014-10-31 09:25:10 UTC
See Bug 525779 for reasons, why autofs mounts aren't shown...
Comment 10 Ondrej Holy 2016-06-10 09:40:00 UTC
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...
Comment 11 Ondrej Holy 2018-03-26 09:33:58 UTC
Just a note that this is also a problem for unmounted btrfs subvolumes, see:
https://gitlab.gnome.org/GNOME/nautilus/issues/328
Comment 12 GNOME Infrastructure Team 2018-09-21 17:42:49 UTC
-- 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.