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 456891 - "Save a copy" doesn't work
"Save a copy" doesn't work
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
git master
Other All
: Normal blocker
: ---
Assigned To: Evince Maintainers
Evince Maintainers
: 469745 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-07-14 16:19 UTC by Johannes Weißl
Modified: 2007-09-04 15:30 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
Fixes the problem, because gnome_vfs_xfer_uri is used instead of gnome_vfs_move. (1.49 KB, patch)
2007-07-14 16:20 UTC, Johannes Weißl
none Details | Review

Description Johannes Weißl 2007-07-14 16:19:05 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:
Comment 1 Johannes Weißl 2007-07-14 16:20:56 UTC
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.
Comment 2 Nickolay V. Shmyrev 2007-07-30 06:38:14 UTC
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.
Comment 3 Nickolay V. Shmyrev 2007-07-30 06:39:50 UTC
I mean bug 309592 is still open, should we close it?
Comment 4 Carlos Garcia Campos 2007-07-30 07:25:27 UTC
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 + ...). 
Comment 5 Johannes Weißl 2007-09-04 10:36:45 UTC
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.
Comment 6 Wouter Bolsterlee (uws) 2007-09-04 10:42:01 UTC
(In reply to comment #5)
> It should be fixed before the next stable release.

Agreed, raising severity.
Comment 7 Carlos Garcia Campos 2007-09-04 10:54:28 UTC
(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
Comment 8 Carlos Garcia Campos 2007-09-04 15:29:27 UTC
*** Bug 469745 has been marked as a duplicate of this bug. ***
Comment 9 Carlos Garcia Campos 2007-09-04 15:30:38 UTC
Done, it should be fixed in svn trunk now. 

Thank you very much for reporting.