Comment 13 for bug 594674

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