Video demonstrating the bug can be found attached to the launchpad post.

This isn't really a bug.

The trash backend currently only tracks trashed files on "user interesting" mounts -- those that g_unix_mount_is_system_internal() returns FALSE for.  This is approximately equal to "stuff mounted in /media/".

The specification doesn't tell us which volumes to support trash in.  It merely says that an implementation "may also choose to provide trashing in the “top directories” of some or all mounted resources.".

It is certainly a bug, however, that nautilus (via g_file_trash()) and the trash backend disagree on which volumes ought to be supported.

Alex?

*** Bug 596323 has been marked as a duplicate of this bug. ***

Well this is certainly not a desired behavior at all, because it leaves the user with hidden files and growing .Trash-folders all over the place, which probably might never be seen (and deleted) by the user. So either fix the trash backend (preferred) or inform the user about that problem when a trash creates such an 'undeletable' folder structure (or disable "Move to trash" and enable "Delete" on those volumes).

Additionally it might be preferable to not hide bind mounts per se, since I doubt they are there unintentionally. Stopping glib from hiding those (_g_get_unix_mounts()) yields the expected trash behavior plus makes the binds visible (only those I am allowed to write to), though the name is wrong (because of the reverse device to mount name lookup, I assume).

Ok, so much for my two cents, but from a user-POV you should get some sane handling there :-)

It's my opinion that we should have Nautilus only support direct-delete in these cases.

*** Bug 619977 has been marked as a duplicate of this bug. ***

This is a GIO bug -- g_file_trash() should be failing for all but user-interesting mounts.

About bug 619977: supporting submounts (particularly bind mounts) inside of the user's home directory is a losing proposition for two reasons:

  1) The expectation that the trashing is done to the user's trash folder (due to the fact that it's part of their home directory) is in conflict with the idea that the trashing should be done to the regular per-device trash folder if the media were to be mounted elsewhere

  2) Trashing to the user's home trash folder in this case would be slow since it involves moving files across filesystems.

I think we won't support this -- but Nautilus should certainly give you an error if you try to do it (instead of silently whisking your files off to some unknown and invisible place).

*** Bug 621670 has been marked as a duplicate of this bug. ***

FYI: I've reported bug #637800 for a tangentially related problem with trashing files outside the user's home directory. (The code paths involved show quite some overlap).

(In reply to comment #2)
> This isn't really a bug.
> 
> The trash backend currently only tracks trashed files on "user interesting"
> mounts -- those that g_unix_mount_is_system_internal() returns FALSE for.  This
> is approximately equal to "stuff mounted in /media/".
> 
> The specification doesn't tell us which volumes to support trash in.  It merely
> says that an implementation "may also choose to provide trashing in the “top
> directories” of some or all mounted resources.".
> 
> It is certainly a bug, however, that nautilus (via g_file_trash()) and the
> trash backend disagree on which volumes ought to be supported.

But why not support all locations that current trash backend does?

It is not only about "weird binds": this also happens with a tmpfs-mounted /tmp. The backend correctly creates a device trash in /tmp/.Trash-1000, so why can't Nautlius list it when it retrieves the list of trashed files in trash://?

(In reply to comment #8)
> About bug 619977: supporting submounts (particularly bind mounts) inside of the
> user's home directory is a losing proposition for two reasons:
> 
>   1) The expectation that the trashing is done to the user's trash folder (due
> to the fact that it's part of their home directory) is in conflict with the
> idea that the trashing should be done to the regular per-device trash folder if
> the media were to be mounted elsewhere

True. Trashing in this case should be done to the regular per-device trash folder, even if it is binded inside the user's home.

... and it is /already/ doing this way. But nautilus is not listing files in that device trash folder.

>   2) Trashing to the user's home trash folder in this case would be slow since
> it involves moving files across filesystems.

Agree. So don't move across filesystems and create the per-device trash folder.

... just like it is /already/ being correctly doing.

> I think we won't support this -- but Nautilus should certainly give you an
> error if you try to do it (instead of silently whisking your files off to some
> unknown and invisible place).

Why not simply show the "unknown and invisible" device trash files when listing the user's trash, just like it currently does with $HOME/.local/trash and all the drives and USB keys in /media/*/.Trash-$UID

Is there a reasonable reason to prevent these per-device trash folders to be included in the trash:// "global" listing, specially since the trash backend is already correctly creating such per-device folders?

Sure, completely disabling support for those is better than current behaviour of "trashing but not listing", but IMHO the best approach would be to support all local mounts where such per-device trash folder can be properly created (properly as in according to XDG's trash spec requirements)

Last but not least: trash-cli package (available for both Fedora and Debian/Ubuntu) is a small python command line software that correctly does what Nautilus doesn't: trash-list command shows the contents of all accessible user trash folders. And since it never crosses moves files across filesystems, speed is not an issue. So maybe it is worth checking out.

Can this behavior be implemented in Nautilus instead of disabling trash for all non-"user interesting" devices?

reassigning to nautilus since it seems the issue is rather on this side

*** Bug 604754 has been marked as a duplicate of this bug. ***

*** Bug 673996 has been marked as a duplicate of this bug. ***

*** Bug 646386 has been marked as a duplicate of this bug. ***

*** Bug 566333 has been marked as a duplicate of this bug. ***

Created attachment 254981 [details] [review]
GIO-Unix: Add API to retrieve all mounts and mount points, including bind ones

Created attachment 254982 [details] [review]
GVFS trashlib: Watch for all mounts including bind ones

Since this seems to be the bug all report like this point too, even though I don't think it's a Nautilus issue but rather a GIO or GVFS one, I'm gonna post here.

As all these bug reports show, the trash hand of GIO and GVFS is inconsistent:  GIO trashes files in the topmost parent directory on the same device as the file to trash, where GVFS only looks for trashes in non-internal non-bind mounts.  This leads to disappearing trashed files.

For bind mounts, there is basically 2 solutions to this: 1) make GIO trash to a global device-sepcific location, or 2) make GVFS look in all *mounts*, rather than devices, for a trash.

1) has an issue raised in #637800, that rename()ing a file doesn't work over mounts, so it's probably not acceptable since it would involve a copy.

2) doesn't seem to have an issue as far as I can tell, it is just a matter of displaying a few more trashes with bind mounts.

Attached are 2 patches, which implements solution 2.  There is one patch against GIO-Unix to expose API to retrieve all mounts, including bind ones, and one against GVFS to use this instead of the version skipping bind mounts.


This however doesn't fix the internal mount issue as e.g. raised in #673996, but fixing this would only be a matter of not ignoring mounts considered "internal" in the trash list.  I'm not sure why the check is here so maybe there is a reason, but I would think that if the user *do* have a trash in such a folder she wants to see it, the mount being considered internal or not is probably not her concern -- especially since she didn't willfully chose that particular trash, just happened to trash a file on this mount.

I think the spec should probably be made a bit more clear on what is expected in cases like this.  Might be worth raising this on the xdg-list to see what other desktops think.

For lack of that, my preferred solution is still to fix g_file_trash() not to work on non-user-interesting volumes.

First of all, I'm heavily damaged by this "bug" as my installations (primarily in italian schools) heavily rely on bind mounts, and totally agree with  Colomban Wendling.
Any chance to see the proposed patches (that I personally find absolutely the best way to go) inserted in an official release?

(In reply to comment #22)
> I think the spec should probably be made a bit more clear on what is expected
> in cases like this.  Might be worth raising this on the xdg-list to see what
> other desktops think.

I finally did it: http://lists.freedesktop.org/archives/xdg/2014-September/013351.html

(In reply to comment #11)
> It is not only about "weird binds": this also happens with a tmpfs-mounted
> /tmp. The backend correctly creates a device trash in /tmp/.Trash-1000, so why
> can't Nautlius list it when it retrieves the list of trashed files in trash://?

The same issue happens with btrfs subvolumes.

This is still not fixed! 

Also I had btrfs subvolumes but I deleted the btrfs subvolume structure later. 
Trash still doesn't recognize that -  my recent regular folders are still treated as if they were btrfs subvolumes by the trash bin - so no showing files in the global trash and leaving all trash within the hidden folders after empying trash. 
 
how to proceed with this? 

It#S important isn't it?

Is someone working on this? 

Is there a workaround other than searching for all hidden trash folders system wide and then deleting them manually? 

One would think that serious problems with the file management as a core system functionality should spark some interest in the gnome dev community... 

My suggestion: 

- nautilus should create a symlink in the trash folder for any file deleted on a mounted folder

- when the users chooses to delete trash nautilus should delete the files in the local trash folders and then follow the symlinks and delete the files on mounted folders 

- last delete the now obsolete and invalid symlink 

- in case a previously mounted folder isn't available anymore display a message offering to delete the trashbins links to these files or keep them for later 

This problem is not a minor bug - it is a complete show stopper for inexperienced users. 

Either they do not find some of their deleted files in the trash (which makes a trashbin system pretty much useless!) or their mounted drive, like a USB disk drive attached to the system, runs out of space after a while since the deleting of trashs leaves the hidden trash on the disk in place and the settings for limiting the space for the trashbin or autoremove settings don't work either... 

So, after all these years still no solution or workaround?

I totally agree.
It's embarrassing that this bug is yet there.
And the proposed patches (that worked flawlessly) are still totally ignored.
Why?

(In reply to Colomban Wendling from comment #20)
> Created attachment 254982 [details] [review] [review]
> GVFS trashlib: Watch for all mounts including bind ones

Pretty sure we don't want new API for that.

Bug 522053 contains a patch set to let g_unix_mounts_get() use libmount; this would allow us to detect the "interesting" mount points and possibly ignore bind mounts or btrfs sub-volumes, as Allison explained in comment #22.

The response to Colomban's query on xdg-list was also that:

> Trash at the mount location, regardless of the file system root. This
> is what GIO's g_file_trash() currently does.
-- https://lists.freedesktop.org/archives/xdg/2014-October/013352.html

which means that GIO should keep doing what it's doing, but we should ignore bind mounts when listing volumes.

I'm rather confused after reading this thread, to be honest.

Currently, g_file_trash moves files to a .Trash folder in the mount root. This is, according to the xdg list what should happen. So the remaining problem is that some of those .Trash folders don't get displayed in Trash:// because they're on mounts that are not considered "user interesting".

The solution is to either stop g_file_trash to trash files to non-"user interesting" mounts, or to make all mounts "user interesting". The preferred solution seems to be the former.

Another problem that's, in my opinion, completely different from to first problem is the definition of "user interesting" mounts in regard to bind mounts. As far as I can see bind mounts are not even considered mounts at all, thus even if they fulfill all other criteria as "user interesting", they won't be shown in Trash://.

I'd love to know why bind mounts are completely ignored and if stop ignoring them is going to break anything.

This is also an issue with ZFS.

Users with ZFS, btrfs, and other affected filesystems (and bind mounts, apparently) expect to have a working trash implementation…

It seems like other implementations of the same XDG specification do what gio does when moving files to the Trash, so I agree with Colomban Wendling that this is a bug in the gvfs trash backend not showing all existing trash content.

Changing gio to not move files in .Trash-XXXX directories on such mounts is not a solution, as there are several other implementations of the XDG specification which do this, and gvfs would still be hiding thrash content from applications that use other toolkits/frameworks/libraries than gio/gvfs.

Recent activity on this bug shows that Tails is not the only project affected by this issue. We should really find an acceptable solution. We have a developper ready to write a fix, but as the last proposed one was not accepted, we'd love the maintainers to specify what they would accept to merge among the proposed solutions.

(In reply to Alan from comment #33)
> Recent activity on this bug shows that Tails is not the only project
> affected by this issue. We should really find an acceptable solution. We
> have a developper ready to write a fix, but as the last proposed one was not
> accepted, we'd love the maintainers to specify what they would accept to
> merge among the proposed solutions.

As far as I know, libmount should be used by default in recent GLib versions. It seems to me that g_unix_mounts_get based on libmount doesn't blindly filter out various mounts as it was done before (although I am not sure what is mnt_table_is_fs_mounted):
https://git.gnome.org/browse/glib/tree/gio/gunixmounts.c#n385

So, is this still really a problem with libmount? If so, something like g_unix_mounts_get_all (attachment 254981 [details] [review]) needs to be probably implemented directly in GVfs, if GLib maintainers don't want to provide necessary API, or change the current behavior... it is not an ideal solution, but we really don't have many options here.

Problem still there in latest Fedora 26. Any idea who is going to fix this and when?

-- 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/glib/issues/251.