GNOME Bugzilla – Bug 172997
When 'replace'ing files/folders, they are deleted instead of trashed.
Last modified: 2021-06-18 15:17:41 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
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 ***
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.
sorry for spam s/rather/rather indisputable/
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).
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.
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.
I believe the option "REPLACE" inherits there will be data loss....
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).
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.
Usability crew, any opinion?
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.
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.
See also bugs #317088, #344881, #417243 and <http://mail.gnome.org/archives/usability/2005-June/msg00007.html>
*** Bug 431352 has been marked as a duplicate of this bug. ***
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.
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.