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 172997 - When 'replace'ing files/folders, they are deleted instead of trashed.
When 'replace'ing files/folders, they are deleted instead of trashed.
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.11.x
Other Linux
: Normal major
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 431352 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-04-07 21:08 UTC by Josh Lee
Modified: 2021-06-18 15:17 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Josh Lee 2005-04-07 21:08:21 UTC
Version details: debian

Drag a file/folder to the desktop when a file/folder with the same name already
exists on the desktop. Nautilus helpfully asks if you want to 'skip' or
'replace' the item. If you choose replace, any files or folders removed by this
operation are *deleted*, not just put in the trash. This is very wrong.

I propose the following:
1. When overwriting a folder with another, show a dialog with buttons "Skip",
"Replace", and "Merge". If replace is chosen, the old folder is moved to the
trash. If merge is chosen, the replaced files from the folder are moved to the
trash.
2. Never allow a folder to be overwritten by a file (or vice versa)! This is bad
and most likely not what the user intended.
3. When a file is replaced by another, show the "Skip" or "Replace" dialog we
have now, but with Replace moving the old file to the trash.

Further reading:
http://daringfireball.net/2005/04/replace
http://daringfireball.net/2003/03/i_love_it_because_its_trash
Comment 1 Sebastien Bacher 2005-04-09 23:25:32 UTC
Thanks for the bug report. This particular bug has already been reported into
our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of 48085 ***
Comment 2 Josh Lee 2005-04-11 21:13:44 UTC
It's not a duplicate. Points 2 and 3 are entirely new (and, I think, rather  As
for point 1, I am asking for two things: a) Trashing files instead of deleting
them (also very important), and b) Changing the dialog so it looks like this:

   ==Conflict While Copying==
   <b>The folder "/home/josh/Desktop/untitled folder" already exists.</b>
   You can merge the incoming folder with the old, or give
   the incoming folder a new name.
   [Skip] [Rename] [Merge]

(I know, this is a little different than what I said before.)

If this bug can be reassigned to gnome-vfs, that's fine, but don't just close it
without any reason.
Comment 3 Josh Lee 2005-04-11 21:15:25 UTC
sorry for spam
s/rather/rather indisputable/
Comment 4 Michaël Arnauts 2005-05-15 19:10:15 UTC
Perhaps the same dialog can be shown if you rename a folder to a folder that
already exists.
Say you have two folders with photos: Folder and Folder_2.
Like it is now, if you want to merge these, you have to enter Folder_2, press
CRTL+A, press CRTL+X, press backspace, double click Folder, press CRTL+V.

It would be better if you just renamed Folder_2 to Folder and then present the
user with the dialog to [Skip] (abort, don't do anything) [Rename] (take a
different name, you don't want to merge) or [Merge] (the thing we want in this
example).
Comment 5 Christian Kirbach 2005-05-15 22:05:02 UTC
why is this wrong?
I'd say this is not a bug; it explicitly asks "replace", i.e. put something else 
in its place (erase the existing file). it is neither "copy" nor "move".

"Merge" is also wrong for the proposed action in my humble opinion. "merge" 
means "make one out of many".

And I'd instantly tag this Priority ENHANCEMENT.
Comment 6 Michaël Arnauts 2005-05-15 22:11:44 UTC
Because there is dataloss involved, this isn't just an enhancement. This is a
bug because when you accidently moves a folder and replaces it, the old one is
gone and there is no way to get it back.
Comment 7 Christian Kirbach 2005-05-15 22:37:29 UTC
I believe the option "REPLACE" inherits there will be data loss....
Comment 8 Josh Lee 2005-05-16 18:50:47 UTC
As opposed to, I don't know, maybe moving the affected file or folder to the
trash can? At the very least, I would accept that (and move the MERGE issue to
another enhancement).
Comment 9 Christian Kirbach 2005-05-17 10:58:51 UTC
OK I think I got your point Josh ... Personally I wouldn't
default the Replace action to move replaced files to the Trash, and I would 
never move an entire already existing folder to the Trash. See comment #7 .
Instead I could imagine a check box
 "Move replaced to Trash"
for the replacement dialogue. Would that satisfy your concern?

I believe the replace/merge options as you suggested will confuse many users. I 
think newbies won't be able to tell the difference. The philosophy of Gnome is 
to keep the Desktop simple and intuitive, for good reasons; I could however 
imagine a dropdown arrow titled "More options" that will expand the dialogue and 
present more sophisticated items.
Comment 10 Christian Neumair 2005-07-13 14:23:09 UTC
Usability crew, any opinion?
Comment 11 Bryan W Clark 2005-07-13 14:42:51 UTC
I don't think people have a concept of what replace does in real world terms,
but don't really know that it means your "Data will be lost", otherwise we could
just put that text in the button.  

If you backed up (by putting it in the trash instead of deleting it) someones
information from a replace operation you'll probably have more happy users than
you will sad ones.  

At the same time if the files are completely identical, then nothing was lost
during the replace operation.  So why would you move it to the Trash then?

I guess I would see value in this if you're preventing people from losing
information, but if you're just swapping out operations it doesn't make complete
sense.
Comment 12 Emmanuel Rodriguez 2007-01-31 18:27:01 UTC
I experienced the lost of data because of the current behavior when replacing a file.

I tried to copy a file from another's user account into my home account, both source and target folders are under the same local file system (ext3). The destination folder already had a file with the same name and I am able to read the source file without problems. When I dragged the source file to the destination folder Nautilus offered me to skip the operation or to replace the existing file. I accepted to replace the existing file. Because I didn't had the rights to remove the original file (the drag motion seems to trigger a move operation no matter the source's file ownership) Nautilus failed the operation but removed the existing target file. Not only the operation failed but my copy of the file was gone!

I think that when a file is copied over an existing file the operation should be atomic: either Nautilus successfully manages to open the file in write mode and then discards the content or the target file as it rewrites it or nothing happens and the target file is left intact. If special care is not taken data lost can happen.

In my case I was lucky to realize that I didn't had copied the file because my folder didn't had a lot of files, but I can easily imagine that some people can think that they performed a copy without knowing that the operation failed.
Comment 13 Calum Benson 2007-04-13 17:04:34 UTC
See also bugs #317088, #344881, #417243 and  <http://mail.gnome.org/archives/usability/2005-June/msg00007.html>
Comment 14 Cosimo Cecchi 2007-12-31 10:32:19 UTC
*** Bug 431352 has been marked as a duplicate of this bug. ***
Comment 15 shankao 2012-12-10 03:46:29 UTC
I tried to reproduce the "move file + cancel the operation" behavior and was not able to. The original file was not removed from the source. Only when I left the move operation to complete, the file removal from the source was performed.

I'm using nautilus 3.6.3 on ubuntu raring.
Comment 16 André Klapper 2021-06-18 15:17:41 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.