GNOME Bugzilla – Bug 632323
merging a link with its target's directory can delete all of the directory's contents
Last modified: 2017-03-22 15:13:48 UTC
If you move a file which is a link to a directory to the target's parent directory nautilus will offer you to merge both of them. The end result is a broken link of a directory to itself and all of its contents removed. If you do it the other way around (you move the original directory), the result is the link replaced with the directory with its contents intact. This behaviour should also happen in the first case (e.g. the link should simple be removed).
Hi Henrique, which Nautilus version is this about? 2.32? And does this still happen with a recent one (like 3.0)?
Hi Henrique, which Nautilus version is this about? And does this still happen with a recent one (like 3.2)?
Sorry, I don't remember which was the original version in which I found this behaviour. Trying it in Nautilus 3.2.1, its behaviour didn't change.
*** Bug 640970 has been marked as a duplicate of this bug. ***
*** Bug 690955 has been marked as a duplicate of this bug. ***
*** Bug 730209 has been marked as a duplicate of this bug. ***
I just discovered this bug. I am using Ubuntu 16.04 and nautilus 3.14.3 Here are my steps how to replicate this bug. From a terminal window starting in my home directory: mkdir useful cd useful touch stuff1.txt touch stuff2.txt cd ../Desktop ln -s ../useful/ useful Now I have a symbolic link on my desktop "useful" that links to directory "useful" containing two files. From nautilus: - Go to Desktop, select the link useful - press Ctrl-X to copy - Go to Home - press Ctrl-V to paste - dialog box appears: Merge folder "useful" - press Merge button (the default) directory useful has now been replaced with a symbolic link pointing to itself, and all its contents are gone. Now in nautilus I press Ctrl-Z to undo. Symbolic link "useful" reappears on the Desktop, but the target folder is not reconstructed. Why is this a important bug: 1. Merge dialog gives no indication that the source is a symbolic link. Instead it asks the user if wants to merge the files in two folders. 2. Continuing with the merge is the default option. 3. After the merge the symbolic link survives and the folder and its contents are utterly gone. They cannot be found in the trash. 4. Undo does not restore the folder or its files, just relocates the symbolic link. I posted this initially to Canonical, bug # 1656370
(In reply to Michael Black from comment #7) > I just discovered this bug. I am using Ubuntu 16.04 and nautilus 3.14.3 Thanks. Testing with recent versions (3.22 or 3.20) highly welcome - 3.14 is already two years old. > I posted this initially to Canonical, bug # 1656370 Link welcome.
I don't have a testbed for more recent versions, but on a whim I did browse through the current stable source code for nautilus and I think that the problem is still there. I followed through the checks that are made when making a copy and I didn't see any particular checks for this bug. Forgive me, this is the probably not the best way of doing it, but this seems like a quick fix: In file "nautilus-operations-ui-manager.c", function "set_copy_move_dialog_text", inside the condition "destination_is_directory" and "source_is_directory", one could add the line if (nautilus_file_is_symbolic_link(data->source) && !nautilus_file_is_symbolic_link(data->destination)) { message="Replace destination folder with symbolic link?"; message_extra="(DON'T DO THIS!!!)"; } This would only run if 1) both source and dest are directories, 2) both have the same names, 3) the source is a symbolic link.
Created attachment 346962 [details] [review] Patch to disable the replace button when a symbolic link is in conflict with a folder As suggested by Michael I wrote a patch to warn the user about this problem and to disable the replace button, so there isn't the risk to delete the destination folder's content. I think it's conceptually wrong replace a folder with a symbolic link.
Review of attachment 346962 [details] [review]: Hey, thanks for this work! I think the API is what we want, but the patch doesn't actually work. I attached a picture of what do I get when trying it out. Also, the commit message doesn't follow the guidelines, please follow: https://wiki.gnome.org/Newcomers/CodeContributionWorkflow#Commit_guidelines ::: src/nautilus-file.c @@ +23,3 @@ #include "nautilus-file.h" +#define G_FILE_ATTRIBUTE_RECENT_MODIFIED "recent::modified" What's this? ::: src/nautilus-operations-ui-manager.c @@ +138,3 @@ if (destination_is_directory) { + if (nautilus_file_is_symbolic_link (data->source) && !nautilus_file_is_symbolic_link (data->destination)) too long, use a 80 character width line style. @@ +348,3 @@ if (source_is_directory && destination_is_directory) { + if (nautilus_file_is_symbolic_link (data->source) && !nautilus_file_is_symbolic_link (data->destination)) ditto. Also use brackets {} for single line code too @@ +354,1 @@ _("Merge")); bad alignment now
Created attachment 347464 [details] Conflict result with patch
Created attachment 347487 [details] [review] Patch to disable the replace button when a symbolic link is in conflict with a folder Ok, now the issues with the patch should be resolved. The original patch doesn't take into account symbolic links related to files.
Review of attachment 347487 [details] [review]: That's an step forward! One thing that still don't work is that if you can see in the screenshot I have a (null) in the strings. Wonder why is it there? Maybe is not related to your patch. Also, it shows "apply this action to all files and folders" that doesn't make sense here. Even worse, if you click this the replace button is back again :(
btw appreciated you took so little to come up with a new patch
ah also the commit message is still not fixed, and pointed out previously
I don't get the problem with the commit message. Can you explicitly tell me the issue? I tried to follow the guidelines. I'll try to fix also the other two issues.
Created attachment 347497 [details] [review] Patch to disable the replace button when a symbolic link is in conflict with a folder Fixed the issues highlighted before. The patch is still incomplete, because I noticed that when the user starts to rename the symbolic link (to avoid the conflict) the "rename" button appears, but if the user choose the same name nautilus will replace the folder (deleting its content). I don't know if it's reasonable to say that in this case is a user fault while nautilus keeps the right behaviour.
(In reply to devim from comment #17) > I don't get the problem with the commit message. "a short title of 50 chars length, followed by a longer explanation of 72 chars length each line" seem to be the two aspects to fix.
Ok, let me know what do you think about the patch, if it's good, I'll fix the commit message. Thanks for the explanaition
(In reply to devim from comment #17) > I don't get the problem with the commit message. Can you explicitly tell me > the issue? I tried to follow the guidelines. > > I'll try to fix also the other two issues. What Andre pointed out and also you are missing the title of the file that you modified. Is it no clear in the wiki?(so I modify it accordingly so anyone understands it) You can also follow the wiki advice and look at any previous commit in the repository to see the format. Regarding your issues, replacing something that we say is forbidden should not happen. Maybe we should just allow to replace it? This actually make sense to allow the user to replace anyway, and will make also the code easier. Any of the choices we take, must be consistent though. What do you think?
It isn't clear that I should include also the title of the file I modified. What to do when there is a large number of modified files? I thought that the changed files are well explained by the diff. In my opinion it isn't good allow this kind of replacement due to a possible unwanted deletion of important files (as said in previous comments). It could be interesting see how the file managers of commercial operating system manage this situation, unfortunately in this moment I can't try.
Created attachment 348017 [details] [review] Patch to disable the replace button when a symbolic link is in conflict with a folder Ok, I fixed the issue described before. The new patch uses gtk_widget_set_sensitive to disable the replace button instead of gtk_widget_hide. This could lead to consistency issues in the code. In fact, all the functions nautilus_file_conflict_dialog_disable_<button_name> use gtk_widget_hide, except nautilus_file_conflict_dialog_disable_replace. What do you think?
I'd like to suggest that the merge option should remain as it is but just delete the source symbolic link. This would look as the result a user would expect from merging two folders (one of then being a symbolic link is not really relevant, I think).
yes, but maybe the source symbolic link could refer to another folder even if it has the same name of the destination folder. Suppose that the user copies all the files contained in a folder to another folder. Now, suppose that in the first folder there is a symbolic link called 'script' that refers to a custom script of the user, while in the destination folder there is another folder called 'script' contained other scripts. Deleting the symbolic link dosen't seem to be the best solution in this case.
If the symbolic link points to another folder, the destination and the pointed folder could be merged, and the destination replaced by the symbolic link.
(In reply to devim from comment #22) > It isn't clear that I should include also the title of the file I modified. > What to do when there is a large number of modified files? I thought that > the changed files are well explained by the diff. > Your are right, my fault, sorry.
Review of attachment 348017 [details] [review]: Now code looks good and works well! The commit message is still missing the guidelines (title too long and file name missing) but I will add that on my end this time. Thanks fro your work!
commited as https://git.gnome.org/browse/nautilus/commit/?id=64f16e19c0dea88e9a992122904d104ecca8b954