GNOME Bugzilla – Bug 456891
"Save a copy" doesn't work
Last modified: 2007-09-04 15:30:38 UTC
Please describe the problem: If the temporary directory and the target directory are not on the same filesystem, "Save a copy" doesn't work (because gnome_vfs_move doesn't work then). Steps to reproduce: 1. Open a PDF 2. Save it to a directory that is on a different filesystem than /tmp Actual results: The target file is absent. Expected results: A copy of the original file should be there. Does this happen every time? Yes. Other information:
Created attachment 91778 [details] [review] Fixes the problem, because gnome_vfs_xfer_uri is used instead of gnome_vfs_move. Fixes the problem, because gnome_vfs_xfer_uri is used instead of gnome_vfs_move.
Thanks a lot for the patch, Johaness. Are you sure it works though? I thought xfer had a bug that prevents move across different file systems.
I mean bug 309592 is still open, should we close it?
The only problem I see with the patch is that this code is running in the main thread, so we should use the async xfer function instead. However, I have in mind to move the save a copy task into a thread, since it could be really heavy (compression + file transfer + ...).
If /tmp is on the same filesystem as the destination, gnome_vfs_xfer_uri just moves the file, so there is no delay. Nothing changes for those who had no problem before. Otherwise there is a very short delay (copying a PDF between two local FS). But of course it could be done async, in that case the distinction between local and remote copying maybe isn't necessary anymore. It should be fixed before the next stable release.
(In reply to comment #5) > It should be fixed before the next stable release. Agreed, raising severity.
(In reply to comment #6) > (In reply to comment #5) > > It should be fixed before the next stable release. > > Agreed, raising severity. > I'll do it
*** Bug 469745 has been marked as a duplicate of this bug. ***
Done, it should be fixed in svn trunk now. Thank you very much for reporting.