Trash is not shown on --bind mounted filesystems

[Otus]

Binary package hint: nautilus

I have a secondary partition, mounted at /media/data, from which I --bind mount a directory to be my ~/Videos using fstab.

When I use Nautilus to navigate into ~/Videos and move a file into trash (either using Delete or by dragging or whatever), the file vanishes, but does not show up when I open Trash from the side panel. If I press Ctrl+H to see hidden files I find a ~/Videos/.Trash-1000 directory, under which the file has been moved.

Navigating to /media/data/path/Videos and removing the file from there moves it under /media/data/.Trash-1000, from where it correctly shows up in the trash can.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: nautilus 1:2.30.1-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
Architecture: amd64
Date: Tue Jun 15 19:03:29 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Release Candidate amd64 (20100419.1)
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: nautilus

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Upstream bug has been marked as duplicate of bug https://bugzilla.gnome.org/show_bug.cgi?id=604015

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Reassigning to glib

[Leif Walsh (leif.walsh)]

This also affects me. I have many directories (Music, Pictures, Videos, Downloads, Documents, etc.) in my homedir that are bind mounts of directories on another partition. If I delete a file with nautilus, inside, say, ~/Music, it is put in /ext/Music/.Trash-1000, but doesn't show up in the system trash dir. I have to manually delete everything in these directories periodically, to reclaim space.

I see this is also an upstream bug, but it seems the discussion there mirrors my own concern, that nautilus should at least show a message and provide a "Delete permanently" option instead of trashing to a folder I wouldn't otherwise see.

[anko roze (anko-roze)]

i can confirm this on ubuntustudio 12.04 with thunar, which also uses gvfs.

i have several directories under my home directory which are bind mounted and the exact same thing described above happens if i delete any file in thunar in any of those directories...

so gvfs trash doesn't work correctly under these circumstances. :(

[[e-mail] (larsoner)]

Confirmed that this (high-priority) bug still exists in 12.04. Let us know if there is any extra information we can provide.

[Sebastien Bacher (seb128)]

@larson.erid.d: not sure it's really a "high-priority bug", such bind mount setups are not common. Could you tell us a bit more of cases where it's a concrete issue and maybe read https://bugzilla.gnome.org/show_bug.cgi?id=604015 to see if you agree with what was said there? Would it solve the issue if nautilus was just directly deleting files on such locations?

[MestreLion (mestrelion)]

My 2 cents for this issue:

- It also happens with tmpfs mounts. I have "tmpfs /tmp tmpfs defaults,nodev,nosuid,mode=1777 0 0" in my /etc/fstab and nautilus also trash files there just fine (creating and moving to /tmp/.Trash-1000), but fails to add that particular trash to the "global" list of trash://. So this is not only a problem with mount --bind

- trash-cli package (a very handy softaware that manages trashcan) correctly list all such trashes (both mount --bind and tmpsf), regardless if files were deleted via nautilus or via trash-put command. So nautilus bug is not about trashing these files, it does this correctly, it's only about listing all available trashcans (one from each filesystem)

Hope this helps narrowing the problem down

[MestreLion (mestrelion)]

@Sebastien: IMHO disabling trash for those mounts (and also for *all* devices outside $HOME and /media) is overkill. Ok, it is better than current behavior, but the best approach would be to support those (already created and populated) per-device trashcans and list them when the user clicks on the trash. If trash-cli can, why can't Nautilus?

[Sebastien Bacher (seb128)]

@MestreLion: did you read the bugzilla bug? it has the details about the issue

[[e-mail] (larsoner)]

Sure. I use --bind mounts to link working directories on various SSDs to a common location that gets backed up frequently. The bind mounts are preferable to symlinks so that backups of the common location (backed up onto slower HDD storage) execute correctly---traversing symlinks is not a reasonable option for me since each of those working directories makes extensive use of symlinks to save space, and dereferencing all of those would replicate a bunch of data, making backups much slower and data restores essentially impossible.

In my case, having a bunch of ".Trash-1000"s hiding is problematic. I work around it currently by making judicious use of "locate" and "find". For me, just having "delete" direct-delete the files---like what happens when you delete a file within a symlinked folder on a different FS---instead of moving them to a ".Trash-1000" folder would be much better, but I can't speak for everyone on this.

In any case, it looks like Rodrigo Silva also has some relevant comments in the bugzilla site linked earlier (https://bugzilla.gnome.org/show_bug.cgi?id=604015).

[Luke (lukekuhn)]

A file in one partition, wherever mounted, cannot be "moved" to any location in another partition, as to place it on a different physical device or a partition of one means copying the file to that location, then deleting it from the original, not just attacking a new path to an existing physical location. If "trash" is a directory in any location, files can only be moved to and from it on the same device or partition as a direct result of this limitation.

A fix for this would require code in a trash manager to copy to trash anything from a different device, deleting it on that device, then copy back to that device and delete from the trash to restore it. This is how "one trash can, many devices" would have to work. Needless to say, trashing any large file would require waiting for copying to complete, as would restoring it. Much of that and many users, especially on slow machines, may prefer separate trash cans for each device.

Consider this result of using such code as proof of what I have just said: : Two empty devices, a file on one, trash on the other. If you could "move" the file to the trash on the other device, then empty trash, a file recovery utility would find TWO copies of the file, one on each device. Since partitions are effectively physical devices as well, that also applies to bind mounts from other partitions.

I don't use the trash at all, instead creating a "secure trash" directory on each magnetic disk that is empted using nautilus-wipe, which does not work from the trash can. Flash drives are worse: they require normal deletion (can use trash) but have to be filled usinng dd to overwrite old files-still won't get everything if a block picks that moment to die and go read-only!

[Stéphane Gourichon (stephane-gourichon-lpad)]

@Sebastien Bacher (@seb128)

> @larson.erid.d: not sure it's really a "high-priority bug", such bind mount setups are not common. Could you tell us a bit more of cases where it's a concrete issue

Sure. This also happens on NFS mounts, which is more widespread than --bind.

> and maybe read https://bugzilla.gnome.org/show_bug.cgi?id=604015 to see if you agree with what was said there? Would it solve the issue if nautilus was just directly deleting files on such locations?

From comments there I understand this happens on any filesystem where user has permissions to create .Trash-* directory on the root, and which was not mounted by gnome stuff (technically : those that g_unix_mount_is_system_internal() returns FALSE for. This
is approximately equal to "stuff mounted in /media/". )

Here's a summary of the problem :

* On the one hand, nautilus happily moves files to mountpoint/.Trash* to put trashed files, on *any* filesystem (where .Trash* exists or nautilus has permissions to create it).
* In the other hand, nautilus shows in trash:/// only *some* filesystems (depending on g_unix_mount_is_system_internal).

So, there no doubt that:
* https://bugzilla.gnome.org/show_bug.cgi?id=604015 is the correct upstream bug.
* Nautilus is inconsistent.
* trash-cli shows that a consistent behavior is possible

From upstream:

> 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/".

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

Anyone to offer a patch to upstream ?

[Franck (alci)]

This seems to still happen on 14.04.

[Holger Mauermann (mauermann)]

Same issue with a btrfs partition, eg. mounted at ~/Videos with mount options 'subvol=@videos'. If I delete a file it doesn't appear in the Trash, but is moved to ~/Videos/.Trash-1000. This folder has to be manually removed because 'Empty Trash' doesn't work.

[Juan Simón (simonbcn)]

The bug still exists...

[Stéphane Gourichon (stephane-gourichon-lpad)]

Hello simionbcn.

Thank you for your participation. Can you elaborate ? Several setups were discussed, we can't guess what is yours.

What is your filesystem setup ? Your version of Ubuntu, of involved packages ?
What steps have you performed ?
Such information helps a lot.

Thanks.

[Juan Simón (simonbcn)]

Ubuntu 14.04

The title of this bug is fairly descriptive: Ubuntu doesn't show in any deleted file in a bind folder. It's indifferent the filesystem, the ubuntu version (this occurs in all Ubuntu versions until now) and the involves packages is described in this bug.

[Juan Simón (simonbcn)]

Ubuntu 14.04

This problem occurs too in symlink folders on another drive:

I have created several symlinks in my home folder to folders in another drive.
I have changed the permissions of that mounted drive:

    drwxrwxrwx 6 root root 4,0K oct 13 17:30 media/

When I delete some file/folder on some of that symlinks, from Nautilus, it's sent to Trash folder in `media` drive:

    $ ll /media/.Trash-1000/
    total 8,0K
    drwx------ 2 simon simon 4,0K oct 13 17:32 files/
    drwx------ 2 simon simon 4,0K oct 13 17:32 info/

but it isn't showed in Nautilus trash.

[Stéphane Gourichon (stephane-gourichon-lpad)]

Thank you simonbcn for these interesting additions (not saying I can do anything about it, but a nautilus developer may pick that as valuable hints about what's wrong).