GNOME Bugzilla – Bug 64668
Copy-n-pasting not-existing file to overwrite file on remote dir only removes remote file
Last modified: 2015-06-17 13:26:10 UTC
When pasting a not existing file to a remote location where a file using the same name already exists, brings up the replace-all/replace/cancel dialog and deletes the remote file on choosing replace. To reproduce: - Make a file called "x" on the desktop - Make a file called "x" on a remote location (I only tried using FTP) - Copy the "x" file on the desktop to the clipboard - Go to the console and remove the "x" file on the desktop - Paste files onto the remote location Expected behaviour: Paste Files menu item should have been disabled, an error dialog should have been shown or even nothing should have happened. Note that when the same thing is done using only local locations, the copy files dialog shows up to copy 0 files. Why this bug can effect average computer users too: I found this bug when I cut-n-pasted an index.html file from my home dir to a remote FTP location and afterwards wanted to paste the file again on a different FTP site. Initially I didn't notice I lost anything (which is why this bug is so bad).
It does seem important to fix this. But the best way to avoid problems like this is to install FAM.
Forgive my ignorance but wouldn't after installing FAM the bug still be there when doing what I described above, but with the "x" file on the desktop being an "x" file on some other FTP directory?
Probably, yes. In fact, in the FTP case, you can still run into trouble if someone deletes the file while you are copying it. I guess in that case the best we can do is to make sure we report the error.
Adding GNOME2 keyword.
Major, because of the data loss involved.
This bug is almost 3 years old, has it been fixed? I suggest increasing it's priority, because this is a serious bug.
Just tested between my local drive and an sftp drive, is still reproducible.
Bumping version...
still here with 2.9
In bug #324930 I described a second scenario that triggers this bug. I reproduce it here for your convenience: * Create a file "A" on a FAT drive; * Create a symlink "A" on your desktop; * Drag the symlink to the FAT drive; => A dialog will pop up asking if "A" should be overwritten; * Choose "overwrite"; => File "A" on the FAT drive is deleted & copying the symlink fails. This is annoying when you want to overwrite "A" with a newer version of the same document. It is catastrophic if symlink "A" was pointing at regular file "A". Bug #324930 should probably be solved separately but I do think this demonstrates that the present bug can show up in obscure cases. --- Now, I haven't contributed a single line of code to GNOME so take what I'm about to say with a grain of salt, but I wonder if the problem couldn't be fixed as follows: 1. Never make the overwrite dialog 'rm' a file, just have it continue the operation at hand; 2. When copying a regular file just do a fopen() (or its gnome-vfs equivalent) and write the content. The problem reported in the present bug would simply have the fopen() fail. 3. When copying a directory or symlink, first read the filename and possible the target file name into memory. Delete the file to overwrite only if this succeeds.
I cannot reproduce this bug. I followed the steps from comment #0 and got this dialog: ___________________________________________________________________________ | . | | / \ Error while copying. | | / ! \ | | /_____\ There was an error getting information about “x”. | | | | v Show more details | | | | Error when getting information for file '/home/antonio/x': No | | such file or directory | | | | [ Cancel ] [ Skip All ] [ Skip ] [ Retry ] | |___________________________________________________________________________| It never tries to replace, so the file on remote file is not deleted. Considering its age, this bug report is likely obsolete now.
Same result here as comment 11. Closing as obsolete.