After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 566333 - Unable to move to Trash with bind mount
Unable to move to Trash with bind mount
Status: RESOLVED DUPLICATE of bug 604015
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.22.x
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-01-02 15:51 UTC by Steph
Modified: 2012-10-26 19:01 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Steph 2009-01-02 15:51:33 UTC
Please describe the problem:
I have the following mount in fstab:
/ws/home      /home           none    bind            0       0


In the above mount, /ws and / are the 2 filesystems root.

The reason to use a bind mount is that /ws contains a lot more than just home.  It's a big disk, and not partitioning the disk leads to better use of the entire disk space.

Steps to reproduce:
1. Use nautilus to delete a file anywhere under /ws/home (see above fstab entry)
 


Actual results:
Pop up window with message:
--snip--
Cannot move file to trash, do you want to delete immediately?
The file "ttt" cannot be moved to trash.
V Show more details
Unable to trash file: Invalid cross-device link
[Cancel][Skip All][Skip][Delete All][Delete]
--snip--

Expected results:
I'd expect nautilus to find the correct root of the device (/ws) so that it can successfully move the file to Trash.

Does this happen every time?
yes

Other information:
Comment 1 A. Walton 2009-01-05 06:28:20 UTC
Can you reproduce this with GVFS from trunk? The trash backend has been rewritten since 2.22 and this may have been resolved.
Comment 2 Steph 2009-02-10 00:41:56 UTC
Don't care.
Comment 3 Allison Karlitskaya (desrt) 2009-02-10 01:29:17 UTC
this is unlikely to be solved since the gvfs trash backend has nothing to do with trashing of files.

i guess the problem here is that gio does a check to see if the filesystem device or ID is the same (which for bind mount, i guess it is) in order to determine if it can rename() across it.  it assumes that, because all info is the same, that it is the same mount.

we could use better checking in this case.  probably this affects more than just trash.
Comment 4 Cosimo Cecchi 2012-10-26 19:01:04 UTC
The part of this bug which is still actual sounds like bug 604015, closing as a duplicate

*** This bug has been marked as a duplicate of bug 604015 ***