Ubuntu

Trash is not shown on --bind mounted filesystems

Reported by Otus on 2010-06-15
96
This bug affects 14 people
Affects Status Importance Assigned to Milestone
GLib
Confirmed
Medium
Nautilus
Invalid
Undecided
Unassigned
glib2.0 (Ubuntu)
Low
Unassigned
nautilus (Ubuntu)
High
Unassigned

Bug Description

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

Otus (jan-varho) wrote :
Otus (jan-varho) on 2010-06-15
description: updated
Changed in nautilus:
status: Unknown → New
Changed in nautilus (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Changed in nautilus:
status: New → Invalid

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

Changed in nautilus:
status: Invalid → Unknown

Reassigning to glib

affects: nautilus (Ubuntu) → glib2.0 (Ubuntu)
Changed in glib:
importance: Unknown → Undecided
status: Unknown → New
Changed in nautilus:
importance: Unknown → Undecided
status: Unknown → New
Changed in glib:
importance: Undecided → Unknown
status: New → Unknown
Changed in nautilus:
status: New → Invalid
Changed in glib2.0 (Ubuntu):
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
Changed in glib:
status: Unknown → Confirmed
Changed in glib:
importance: Unknown → High
Leif Walsh (leif.walsh) wrote :

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) wrote :

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. :(

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) wrote :

@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?

Changed in glib2.0 (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
Changed in nautilus (Ubuntu):
status: New → Triaged
importance: Undecided → High
MestreLion (mestrelion) wrote :

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) wrote :

@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) wrote :

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

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) wrote :

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!

@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 ?

Changed in glib:
importance: High → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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