Folder is overwritten with a file with the same name

Bug #95854 reported by Andrei Drynov on 2007-03-25
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)
Medium
Unassigned

Bug Description

Upstream report:
https://bugzilla.gnome.org/show_bug.cgi?id=425980

Binary package hint: nautilus

1) lsb_release -rd
Description: Ubuntu Vivid Vervet (development branch)
Release: 15.04

2) apt-cache policy nautilus
nautilus:
  Installed: 1:3.14.2-0ubuntu2
  Candidate: 1:3.14.2-0ubuntu2
  Version table:
 *** 1:3.14.2-0ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages
        100 /var/lib/dpkg/status

3) What is expected to happen is when one executes the following in a terminal:
cd ~/Desktop
mkdir test
cd
touch test

then uses Nautilus to copy the file test to the Desktop, it does not allow this, just like it won't when using cp in a terminal:
cp test Desktop/
sudo cp test Desktop/
cp: cannot overwrite directory ‘Desktop/test’ with non-directory

or if one was using Windows.

4) What happens instead is one gets a prompt noting:
File Conflict
Replace folder "test"?
A folder with the same name already exists on "desktop".
Replacing it will remove all files in the folder.
Select a new name for the destination
Apply this action to all files
Cancel Skip Replace

and if one accidentally hit the button Replace, the folder with all of its contents are permanently deleted, and replaced with the file.

ProblemType: Bug
Architecture: i386
Date: Sun Mar 25 11:49:14 2007
DistroRelease: Ubuntu 7.04
Uname: Linux acer 2.6.20-12-generic #2 SMP Wed Mar 21 20:55:46 UTC 2007 i686 GNU/Linux

Laurent Bigonville (bigon) wrote :

I've just tested and I get a warning saying that the folder already exists

Andrei Drynov (adrynov) wrote :

I admit - not well-written bug.

There is a warning. Unfortunately, the folder with rich contents WILL get replaced by a file if you accept.

Behaves differently on Mac OS X and Windows.

Daniel Holbach (dholbach) wrote :

What do you suggest?

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist
status: Unconfirmed → Needs Info

Daniel, a couple of ideas:

1. Do not allow to overwrite a folder with a file

In Unix it is not possible anyway...

dhcp1k250:~/Desktop Andrei$ mkdir test
dhcp1k250:~/Desktop Andrei$ cd
dhcp1k250:~ Andrei$ touch test
dhcp1k250:~ Andrei$ cp test Desktop/
cp: cannot overwrite directory Desktop/test with non-directory test

Why does Nautilus overwrite the folder?

2. Give an explicit warning: "You are overwriting the folder @s with a file
@s. All the contents of the folder will be destroyed. Are you sure?"

It is somewhat Windows-like behaviour, but what the heck? It is data that is
being destroyed.

And please do not set Importance to Wishlist. I know at least three people
that lost some important stuff in this way. (This is a hard way to finally
to learn to backup 8-)))

On 29/03/07, Daniel Holbach <email address hidden> wrote:
>
> What do you suggest?
>
> ** Changed in: nautilus (Ubuntu)
> Importance: Undecided => Wishlist
> Assignee: (unassigned) => Ubuntu Desktop Bugs
> Status: Unconfirmed => Needs Info
>
> --
> Folder is overwritten with a file with the same name
> https://launchpad.net/bugs/95854
>

--
С уважением,
Сибиряк

Sebastien Bacher (seb128) wrote :

There is a dialog asking you if you want to override the directory and you acknowledge it, not really a nautilus bug. I've opened a bug upstream anyway: http://bugzilla.gnome.org/show_bug.cgi?id=425980. The bug is low importance though, user can read the dialog and then click on ok or not

Changed in nautilus:
importance: Wishlist → Low
status: Needs Info → Confirmed
Changed in nautilus:
status: Unknown → Unconfirmed

I'm not sure if this is a fix or not, but I can not reproduce with Nautilus 2.21.6 on Hardy Alpha. When moving the file into the directory of the folder with the same name, you first receive the replace/skip/cancel dialog:

     "A folder named "Videos" already exists. Do you want to replace it?

     The folder already exists in "/home/ubuntu". Replacing it will remove all files in the folder."

Then if you ok replacing the folder, you receive the following error and the operation is canceled.

     "Error while moving.

     Error opening directory '/home/ubuntu/Desktop/Videos': Not a directory"

As for the first dialog, it seems like a pretty clear warning, but as we know users will often click right through those with out reading.

As for the error message, I'm not sure if it was related or a separate issue. Any one else try this on Hardy?

Changed in nautilus:
status: Confirmed → Incomplete
Pedro Villavicencio (pedro) wrote :

I cannot reproduce this bug either in Hardy and I get the same messages as Andrew and the folder of course isn't replaced, for me the bug is now fixed.

Changed in nautilus:
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

the comments seem to indicate it's fixed in hardy, closing the bug, feel free to reopen if you still get the issue though

Changed in nautilus:
status: Incomplete → Fix Released
Aivars Lauzis [LV] (lauzis) wrote :

Hello!

Just overwrote file over directory...
sorry, but for me its bug...
why shoud somebdy overwrite file over folder, anywhay?

also you can not create folder/file if there is already file/folder already with same name...
this is crazy...

i dont like it all.. because also if file exists and someone is copying folder in that directory.. it also overwrites it...

is there way to recover something?

Hrotkó Gábor (roti-al) wrote :

Hi!

 Last week I overwrited my Desktop with a file.
I can't reproduce it, but these were the steps:
- in opera chose to download a file
- in the save file dialog, I used the keyboard to navigate to Desktop folder
- after some letter, I quickly hit enter
- the file overwrited my Dektop dir

It was so quick, so I didn't see anything, looked only the keyboard.

If a warning appeared, I think the default answer should be "No"!

Now I can't reproduse it in any way, but I will be much safer in the future.

Roti

cumulus007 (cumulus-007) wrote :

Damn. 1 hour of compiling is lost by this bug!

ortango (ortango) wrote :

This is absolutely a bug, i can't believe that its been open this long with no fix.
As Andrei Drynov added before, you can not reproduce this behaviour outside nautilus, when you attempt to do this in a terminal it throws an error "mv: cannot overwrite directory X with non-directory". I bet Search Results Konqueror doesnt function this way either.
Being that the effects are so extreme i really think this is important.
Currently i am using ubuntu Intrepid Ibex nautilus 2.24.1 and this still is a problem.

Pedro Villavicencio (pedro) wrote :

its still open upstream re opening this task due to user comments, thanks all

Changed in nautilus:
importance: Low → Medium
status: Fix Released → Triaged
lophie (lophesuicire) wrote :

I have a small note. I faced the same problem but my file was actually inside the folder and I want to replace the folder with the file then After I accepted the replacement it nautilus deleted the folder then gave me an error about it couldn't find my file and I didn't find it in the trash so I lost it forever!

i have the same problem.
recently i try to move some file into mi documents folder that contains a folder with the same name and i replace and i lost all my files!!!

Hrotkó Gábor (roti-al) wrote :

I couldn't reproduce it on 8.04.
With Jose's technic nautilus warned me that a folder exists with the same name and will be overwritten.
In mc it will refuse to overwrite, because the folder exists.

Changed in nautilus:
importance: Unknown → Medium
TBeholder (turbobeholder) wrote :

Ran into this one too, in a different way.
What makes it even worse: if you merge directories, it's MUCH more likely than usual that at least one of them contains symlinks into another. And then moved symlinks overwrite their own destinations. With files you at least retain something useful...
I just tested it meging two ".../test/" - destination contained a real non-empty subdirectory and source contained symlink to it with the same name. Oh, yes, nautilus does ask whether to overwrite. The problem: it asks this -

File conflict
Merge folder "1"?
Another folder of the same name exists in "test"
...

["folder" icon] Original file
Size:(null)
Last modified: 11:22

["folder" icon] Replace with:
Size:(null)
Last modified: 11:33

Which gives an impression that they are of the same type and both are empty - while neither is true. Thus the user trusting the dialog is going to confirm, and have the real directory overwritten with now-broken link.

Andrei Drynov, this is not reproducible in Trusty.

The item could not be renamed.
The name “test” is already used in this location. Please use a different name.

Changed in nautilus (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
status: Triaged → Invalid
TBeholder (turbobeholder) wrote :

Nope.
I just now did it again in nautilus/trusty (1:3.10.1-0ubuntu9.4). Even after "nautilus --quit" and "rm -rf ~/.config/nautilus" in case it was my old config.
Steps to reproduce:
1) create your crash test dummies:
$mkdir /tmp/test_real ; mkdir /tmp/test_real/foo ; mkdir /tmp/test_link ; ln -sT "/tmp/test_real/foo" /tmp/test_link/foo
2) open "/tmp/test_real" and "/tmp/test_link" in two tabs
3) copy- or move- drag "foo" from "/tmp/test_link/" into "/tmp/test_real/"
4) nautilus will ask non-indicative question (see above)
5) observe symlink "foo" (pointing at itself and marked as bad, of course) where the original "foo" once was.

The same happens while merging a nested directory (try with /foo/bar if you have doubts) - and then the user have absolutely no hints about what's going on, and data loss will happen.

TBeholder (turbobeholder) wrote :

The difference with a text file is that it shows with a proper icon rather than the same "folder" icon, and nautilus specifically asks to overwrite rather than merge. But on symlinks nautilus asks "Merge folder?" and then actually overwrites.

tags: added: trusty
description: updated

TBeholder, thanks for the follow up. The way I was going about it was not an apples-to-apples test of what was originally reported against in https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/95854/comments/4 . I think the edited Bug Description will make it clear to all the scope of the issue.

Thank you for your understanding.

description: updated
Changed in nautilus (Ubuntu):
status: Invalid → Triaged
tags: added: vivid
tags: added: fiesty
TBeholder (turbobeholder) wrote :

Which is the trouble with this bug: it's actually several otherwise very minor shortcomings that add up to a nasty result.
Apples-to-apples check did fix one problem, but it's circumvented via another.

The second "big" deal, of course, is that usually symlinks are treated as their targets, but using this approach in ALL contexts indiscrimiately is bad.
But.
The dialog itself is flawed: it's important enough to show more than a tab does, and it shows less.
Icons are good, but why the usual overlaid emblems are NOT applied in confirmation dialog? Then symlink would be at least clearly marked as such.
Then, there's "Size:(null)" for directories. Sure, looking inside slows down the huge list - but in the dialog there's only one item and for merging/overwriting purpose it's kind of important what's inside it, so perhaps settings different from the file list (and more verbose by default, at least on "X files + Y directories" level, though seeing the size of at least of immediately contained files would help too) would improve the situation.

Speaking of dialog, overwriting a directory with file is already unusual enough that perhaps this should be a separate category for "apply to all" purpose - just to be on the safe side. Merging a newer directory into old may call for overwrite of old files, but this shouldn't easily lead to something so strange and drastic.

Changed in nautilus:
importance: Medium → High
Changed in nautilus:
status: Confirmed → Invalid
no longer affects: nautilus (Ubuntu)
affects: nautilus → nautilus (Ubuntu)
Changed in nautilus (Ubuntu):
importance: High → Undecided
status: Invalid → New
importance: Undecided → Medium
status: New → Triaged
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.