GNOME Bugzilla – Bug 311591
gnome-vfs copy operation deletes the existing file
Last modified: 2010-05-13 08:59:44 UTC
Attached is a test program which attempts to copy a file using gnome_vfs_xfer_uri(). If the source and destination uris are exactly the same i.e. we are trying to overwrite the file onto itself then the file gets deleted. One example of this operation is in eog. 1. Open a file in eog (say a.png) 2. Select SaveAs from the File menu 3. Locate the folder in which the a.png resides. 4. Give the filename to be saved as a.png (so we are trying to copy a file onto itself) 5. Eog throws up a dialog asking whether we want to overwrite the file. Select overwrite in that. Bug: Eog throws up an error dialog saying "File not found" And the file a.png has been deleted.
Created attachment 49773 [details] Test program
gnome_vfs_xfer_uri () takes one parameter called overwrite_mode which determines what is to be done in case the destination file already exists. When set to REPLACE, gnome-vfs silently attempts to replace the file. So first removes the destination file and then copies the source file onto the destination. In this case source and destination files are the same. So after removing the file, it does not find it for the copy operation and throws up the error dialog saying "File not found". Checking whether user is trying to overwrite the file onto itself and skipping the operation resolves the problem. Attaching a patch here..
Created attachment 49776 [details] [review] Suggested fix
I feel if the image is not modified and the user is trying to copy the file onto itself then eog should throw up a dialog telling that the file is not modified and user is trying to copy the file onto itself and then it should simply abort the operation. But the test case still holds good.
*** Bug 312707 has been marked as a duplicate of this bug. ***
attachment 49776 [details] [review] doesn't do anything for the testcase in bug 312707 though -- gnome_vfs_uri_equal is a fairly weak check for sameness, and fails if the one of the paths has symlinks, or we're transferring across methods, or other such twisted scenarios... I made a few fumbling patch attempts in bug 312707, that are based on the same false assuption as attachment 49776 [details] [review] here, namely, that it's possible to fix xfer doing fs changes in a dangerous order by looking at the uris and files beforehand. It's not, really; we don't have access to such high quality information in the general case. I have this patch in the works that reorders things a bit so as to make the xfer ops safe -- whether it works across all methods, I've no idea :) That said, attachment 49776 [details] [review] sounds like a good fast-path check, especially since the fs change reordering thing isn't all that capable of giving useful errors.
Created attachment 50714 [details] [review] patch3: move aside in-the-way targets - in the pre-flight stage, for conflicts that are to be resolved by replace, don't immediately delete the conflicting item; instead, store the clobber decision in a hash set - in the transfer stage, when about to transfer each item, check if the target is in the set of items to replace; if so, move it aside with a unique rename - after transfer of each item, restore or delete its target backup, if any This way all the scenarios where the source is the target should cause the transfer to fail safely.
Some comments and another (failed) approach in: http://mail.gnome.org/archives/gnome-vfs-list/2005-August/msg00031.html
I'm not sure i like the move-away approach. Its quite complicated, increases the amount of i/o, creates new names in the filesystem (really bad if the filesystem is e.g. a subversion repository or some other strange fs) and generally sounds a bit fragile. I don't have a good solution though...
I agree with Tuukka that we should commit the patch in attachment 49776 [details] [review] even though its not a full fix. Its cheap and fixes some cases. So, i commited it.
Is this still a problem in a recent GNOME version (2.28 or 2.30) which uses gvfs instead of the deprecated gnome-vfs? If this is still an issue for gvfs please file a new bug report against gvfs with good steps to reproduce, or move this existing report to the product gvfs. If this is not an issue anymore in a recent GNOME version, please close this report as RESOLVED OBSOLETE.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!