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 632323 - merging a link with its target's directory can delete all of the directory's contents
merging a link with its target's directory can delete all of the directory's ...
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
3.12.x
Other Linux
: Normal blocker
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 640970 690955 730209 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-10-17 00:17 UTC by Henrique Ferreiro
Modified: 2017-03-22 15:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to disable the replace button when a symbolic link is in conflict with a folder (4.21 KB, patch)
2017-03-01 11:00 UTC, devim
none Details | Review
Conflict result with patch (102.84 KB, image/png)
2017-03-08 10:31 UTC, Carlos Soriano
  Details
Patch to disable the replace button when a symbolic link is in conflict with a folder (4.06 KB, patch)
2017-03-08 14:29 UTC, devim
none Details | Review
Patch to disable the replace button when a symbolic link is in conflict with a folder (4.23 KB, patch)
2017-03-08 19:14 UTC, devim
none Details | Review
Patch to disable the replace button when a symbolic link is in conflict with a folder (4.25 KB, patch)
2017-03-15 17:10 UTC, devim
accepted-commit_now Details | Review

Description Henrique Ferreiro 2010-10-17 00:17:51 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).
Comment 1 André Klapper 2011-08-10 11:32:20 UTC
Hi Henrique, which Nautilus version is this about? 2.32? And does this still happen with a recent one (like 3.0)?
Comment 2 André Klapper 2012-02-06 15:53:45 UTC
Hi Henrique, which Nautilus version is this about?
And does this still happen with a recent one (like 3.2)?
Comment 3 Henrique Ferreiro 2012-02-06 17:16:47 UTC
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.
Comment 4 António Fernandes 2013-04-22 22:57:48 UTC
*** Bug 640970 has been marked as a duplicate of this bug. ***
Comment 5 António Fernandes 2013-04-22 22:57:53 UTC
*** Bug 690955 has been marked as a duplicate of this bug. ***
Comment 6 António Fernandes 2014-05-30 12:24:21 UTC
*** Bug 730209 has been marked as a duplicate of this bug. ***
Comment 7 Michael Black 2017-01-13 18:02:52 UTC
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
Comment 8 André Klapper 2017-01-13 22:12:54 UTC
(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.
Comment 9 Michael Black 2017-01-14 18:19:19 UTC
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.
Comment 10 devim 2017-03-01 11:00:19 UTC
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.
Comment 11 Carlos Soriano 2017-03-08 10:30:47 UTC
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
Comment 12 Carlos Soriano 2017-03-08 10:31:22 UTC
Created attachment 347464 [details]
Conflict result with patch
Comment 13 devim 2017-03-08 14:29:04 UTC
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.
Comment 14 Carlos Soriano 2017-03-08 15:01:54 UTC
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 :(
Comment 15 Carlos Soriano 2017-03-08 15:05:45 UTC
btw appreciated you took so little to come up with a new patch
Comment 16 Carlos Soriano 2017-03-08 15:06:52 UTC
ah also the commit message is still not fixed, and pointed out previously
Comment 17 devim 2017-03-08 18:33:11 UTC
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.
Comment 18 devim 2017-03-08 19:14:03 UTC
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.
Comment 19 André Klapper 2017-03-08 19:17:31 UTC
(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.
Comment 20 devim 2017-03-08 19:20:47 UTC
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
Comment 21 Carlos Soriano 2017-03-08 19:36:14 UTC
(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?
Comment 22 devim 2017-03-08 20:47:37 UTC
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.
Comment 23 devim 2017-03-15 17:10:44 UTC
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?
Comment 24 Henrique Ferreiro 2017-03-16 09:56:23 UTC
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).
Comment 25 devim 2017-03-20 16:25:51 UTC
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.
Comment 26 Henrique Ferreiro 2017-03-21 09:20:16 UTC
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.
Comment 27 Carlos Soriano 2017-03-22 14:42:00 UTC
(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.
Comment 28 Carlos Soriano 2017-03-22 15:07:56 UTC
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!