Ubuntu
glib2.0 package

nautilus trash doesn't include btrfs and zfs subvolumes

Bug #1442649 reported by Karl-Philipp Richter
176
This bug affects 44 people
Affects Status Importance Assigned to Milestone
GLib
Fix Released
Unknown
gvfs
New
Unknown
glib2.0 (Ubuntu)
Triaged
Medium
Unassigned
gvfs (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Files in `/path/to/subvolume/.Trash-1000` aren't listed in the global trash.

Comment by bug triage team: comment 4 has a spot-on analysis of where this issue is coming from, an inconsistency between trash handling in gvfs and glib/gio. The problem has been around for quite a while.

See original description
Revision history for this message
Karl-Philipp Richter (krichter722) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in nautilus (Ubuntu):
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
Revision history for this message
Christian Juner (christian-juner) wrote :

The trouble seems to stem from glib's way of deleting files being different to the way gvfs tries to locate trash directories.

glib's gio/glocalfile.c contains the find_mountpoint_for function which is used to determine the device's root directory as location to put the .Trash-<uid> directory. It looks at the stat(2) st_dev value ("device number"). btrfs gives each subvolume a different device number.

gvfs's trashlib searches for trash directories based on mount points determined by getmntent_r(2).

I do not know how to fix it in general. A fix for btrfs might be to search for all subvolumes of a btrfs mount point returned by getmntent_r(2). Not sure if you can listen to new subvolumes being created after the initial search, though (maybe inotify can?).

Revision history for this message
Rolf Leggewie (r0lf) wrote :

I can confirm the problem for btrfs subvolumes.

This problem is not limited to btrfs subvolumes. The same bug also affects at least ZFS mount points: bug 1390828, samba network mounts: bug 457047, --bind mounted directories: bug 594674, NFS mounts same bug comment 13 and tmpfs mounts same bug comment 8.

Increasing importance from low to medium as the root problem ends up affecting a much wider set of installations than initially thought.

Changed in nautilus (Ubuntu):
importance: Low → Medium
description: updated
Rolf Leggewie (r0lf)
tags: added: karmic trusty utopic
removed: third-party-packages
Changed in nautilus (Ubuntu):
status: Confirmed → Triaged
Changed in gvfs (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Rolf Leggewie (r0lf)
Changed in glib2.0 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Bug Watch Updater (bug-watch-updater)
Changed in glib:
importance: Unknown → Medium
status: Unknown → Confirmed
Jan Claeys (janc)
summary: - nautilus trash doesn't include btrfs subvolumes
+ nautilus trash doesn't include btrfs and zfs subvolumes
Revision history for this message
Ken Mollerup (kenmollerup) wrote :

The problem manifest itself on ext4 formated volumes, and Thunar!

Bug Watch Updater (bug-watch-updater)
Changed in glib:
status: Confirmed → Incomplete
Revision history for this message
Stuart Bishop (stub) wrote :

Work around is to use the trash-cli package and empty trash from the command line.

Upstream fixes in nautilus seems stalled, per https://bugzilla.gnome.org/show_bug.cgi?id=604015 , with no comments from maintainers for the several months that patches have been available.

Bug Watch Updater (bug-watch-updater)
Changed in glib:
status: Incomplete → Expired
Mathew Hodson (mhodson)
Changed in glib:
importance: Medium → Unknown
status: Expired → Unknown
no longer affects: nautilus (Ubuntu)
Bug Watch Updater (bug-watch-updater)
Changed in glib:
status: Unknown → Fix Released
Changed in gvfs:
status: Unknown → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

Is that still an issue in focal?

Revision history for this message
Esokrates (esokrarkose) wrote :

@seb128: Yes that's still an issue unfortunately (tested with btrfs subvolume).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.