GNOME Bugzilla – Bug 312506
can't delete symlink to other filesystem
Last modified: 2008-01-16 11:51:10 UTC
Please describe the problem: Nautilus can't delete a symlink to a folder which is on another filesystem Steps to reproduce: 1. open in nautilus /mnt/somethink-mounted 2. open your home in another nautilus 3. create a symlink of /mnt/somethink-mounted in your home 4. try to delete the link Actual results: first i've got a message like "can't delete other filesystem" but now when I try to reproduce, delete (or "moving to trash") just do nothing. symlink isn't deleted and nautilus doesn't send any error. Expected results: symlink shoud be deleted Does this happen every time? yes Other information:
I think this will be fixed in Nautilus 12.1.
We've just released Nautilus and GnomeVFS 2.12.1. Maybe you could upgrade both and test whether this works for you?
Ok fixed. But I don't undersand why we can't delete the symlink ? I think there should be somethink like "do you want to delete de link or the files pointed by it ?". Because the only choice I have is open a terminal and "rm" manualy the link...
> (...) I don't undersand why we can't delete the symlink ? You're still unable to delete the symlink?
I can't delete symlinks which points to another filesystem. But unlike when i've made this bug, now the error message is displayed everytimes (note only first time).
Hrm this indeed still seems to be an issue.
I confirm this problem and I found the origin after some debugging. This bug can happen when: - you have a symlink with point to a different filesystem (ex: ~/Desktop/dir1 -> /mnt/fs1/dir1) - the symlink filesystem has a trash (ex: ~/.Trash) - the target filesystem can't have a trash (ex: /mnt/fs1 is not writable by the user) The problem is that nautilus first checks if a uri can be moved to trash by searching for a trash on the parent uri volume (function can_move_to_trash), but when it must do the operation it searches for the trash on the original uri (function nautilus_file_operations_copy_move). In our case, the first check return true, because the trash corresponding to the parent uri ~/Desktop/ exists, it is ~/.Trash. but the move fails, because ~/Desktop/dir1 which is resolved to /mnt/fs1/dir which can't have a Trash.
The easy solution would be to find the trash directory using source_uri_dir in nautilus_file_operations_copy_move, but I do not know gnome vfs enough to guess if it can break something. I don't understand how gnome_vfs_find_directory is supposed to work, I wouldn't have expected it to resolve symlinks.
Created attachment 53386 [details] [review] Possible fix to the symlink delete bug I applied the following patch, and I can now correctly delete symlink pointing to another filesystem. It applies on cvs version 1.196 of the file.
Sorry for not having notified you, but I've submitted a similar patch for review: http://mail.gnome.org/archives/nautilus-list/2005-October/msg00077.html
Oh ok and a better patch. I filled another bug which could be linked to this one (the confirmation dialog shows up only the first time): http://bugzilla.gnome.org/show_bug.cgi?id=318723 Can you have a look ?
Updating bug version to Nautilus 2.13.
Manny: Could you fix this in 2.12 as well? I see a string change, but this feels important (and annoying) enough to fix for 2.12.
I can confirm this in Nautilus 2.12.1 as well.
This bug is still not fixed in 2.14.1 ! there is two patch proposed, are they good enough to be commited ?
I confirm this bug in 2.12 and 2.14.1. This bug is really annoying for people that don't know how to use command line: they can't delete these links.
I get the exact same behaviour with Gnome 2.16 on Gentoo. When I try to delete a symlink, I get the following error message: Error "Not on the same file system" while deleting "/home/alex...top/Bilder". Would you like to continue? [ Cancel ] [ Retry ]
Isn't this bug a dupe of Bug #44980 ?
I still have this bug with 2.16.1
I can confirm it too, also with nautilus 2.16.1
Confirmed with nautilus 2.17.90
*** Bug 443087 has been marked as a duplicate of this bug. ***
I still have a similar bug with nautilus 2.20.0. I still can't delete symlinks to other filesystem, however now no error dialog is displayed.
The patch from Christien Neumair http://bugzilla.gnome.org/show_bug.cgi?id=312506#c10 still seem to solve this bug. Why hasn't been applied ?
Created attachment 97574 [details] [review] This patch solves the bug in gnomevfs I found the reason why the previous patch was not applied: http://mail.gnome.org/archives/nautilus-list/2005-October/msg00159.html So here is a new patch that tries to follow Alexander Larsson's advice.
commited.
Sorry to not have posted earlier but his patch has side effects: - it prevents can_move_uri_to_trash to work properly in nautilus, as nautilus already gives the parent_uri to the gnome_vfs_find_directory function. The attached patch 41_don_t_use_parent_uri_to_find_trash.patch solves this bug. - gnome_vfs_find_directory will not return the good trash if used on the mount point. I don't know what is expected in that case (the mount point usually can't be put to trash after all) and if existing applications relied on this behaviour. The attached patch 34_fix_find_directory.patch restores this behavior if required. However, as gnome-vfs will be replaced with gvfs, I wonder it it's a good idea to introduce this kind of changes. Nautilus might be not the only application which gives the parent uri to gnome_vfs_find_directory, so maybe Christian Neumair's patch http://mail.gnome.org/archives/nautilus-list/2005-October/msg00077.html is a better solution, it only fixes the bug for nautilus but has no side effect. What do you think ?
Created attachment 102044 [details] [review] Don't give the parent_uri to the gome_vfs_find_directory function
Created attachment 102045 [details] [review] Don't use the parent_uri in gnome_vfs_find_directory if the given uri is a mount point
I've reverted the patch. Lets just keep gnome-vfs as it was and focus on gvfs.