Version: 0.5.7 (using KDE 3.5.7, ALT Linux i586) Compiler: Target: i586-alt-linux OS: Linux (i686) release 2.6.18-std-smp-alt7 1. Open PDF document in KPDF 2. Rename opened file (or delete it) 3. Try to save opened document. Result: KPDF unable to save opened document. There is only KPDF doesn't save opened (but deleted) document in all PDF viewers.
Wish
Confirmed here with Qt: 3.3.8b KDE: 3.5.9 KPDF: 0.5.9. How this occurred for me: Open a pdf from the web (with firefox) in kpdf, close firefox. Apparently the copy cached in /tmp got deleted automagically at this point. * A further problem here is that kpdf reports that "Cannot save file:///home/me/abc.pdf, please try saving somewhere else." (Translated, but to that effect.) * This is the same longstanding issue as bug 114485, that report should be reopened.
(In reply to comment #2) > How this occurred for me: Open a pdf from the web (with firefox) in kpdf, close > firefox. Apparently the copy cached in /tmp got deleted automagically at this > point. This is a Firefox problem, reported as: https://bugzilla.mozilla.org/show_bug.cgi?id=437767 See also Okular's bug 163363 about why we cannot keep the file open. > This is the same longstanding issue as bug 114485, that report should be > reopened. Given the uncomplete information of the original report of #114485, you cannot say that they are the same.
Thank you for your response and the information. "Given the uncomplete information of the original report of #114485, you cannot say that they are the same." I beg to differ. Of course, the original report of bug 114485 misses a complete explanation, so we cannot be sure, but the symptoms are clear. What I am reporting is that the same symptoms - from bug 114485 - are caused by the procedure reported here, in bug 150699. That is, the error message "File could not be saved in 'file:///home/me/abc.pdf'. Try to save it to another location." However, it doesn't really matter in the end whether the issue be tracked here or there. * Let me restate a reproducible case, or, more exactly, two parallel but absolutely equal cases, 1a. Open a local pdf file in kpdf, or 1b. Use Firefox to open a remote pdf file in kpdf - this causes a temporary local file to be created by Firefox and opened by kpdf. 2a. Remove, move or rename the opened local file. 2b. Close Firefox, which causes the temporary local file to be removed. Or, to get the same effect, remove, move or rename the temporary file manually. 3a and b. Try to save the file from kpdf. No-go, and you get the error message quoted. To add a parallel case, do the same with (for example) acroread, and the end result is different: 3c. Try to save the file from acroread. Works as expected. * Now, whether this is a kpdf problem or a Firefox problem. From a user's point of view, it is definitely a kpdf problem. It's a case where kpdf "has the document", but simply can't save it. Is this a kpdf problem from the application designer's point of view? I can not tell, as I'm not that person. A quote from the Okular report you referenced: "Another way to solve it might be to keep opened files in swap or a cache..." As mentioned, for example acroread manages to save a file it "currently has open". Apparently they must keep the file cached somewhere or use other magic to achieve what they do. Is it a good policy to depend BOTH on other programs not tampering with the file on the disk AND on the user not moving or removing the file while viewing it in kpdf? I would say no. I would say it is better for the program to be self-reliant, but it is not my decision to make.
(In reply to comment #4) > I beg to differ. Of course, the original report of bug 114485 misses a complete > explanation, so we cannot be sure, but the symptoms are clear. Same symptoms could be originated from different causes, so just forget that bug (like the original reporter seems to have done) and concentrate on this one, ok? > Let me restate a reproducible case, [...] ... as already documented in okular's bug 163363. > Now, whether this is a kpdf problem or a Firefox problem. From a user's point > of view, it is definitely a kpdf problem. Especially when firefox removes the downloaded files, it happens with any application out there that is started that way. > As mentioned, for example acroread manages to save a file it "currently has > open". Apparently they must keep the file cached somewhere or use other magic > to achieve what they do. They can do that as they have no "watch file" function, I suppose. So, if you choose to watch your documents for changes, keeping the file open breaks this feature (and I think that the users of that would not be happy). What's worse, you have exactly no way to distinguish when it's firefox that calls kpdf/okular or you from your file manager or anything else, because the only file you get is the the one in /tmp/whatever, downloaded by firefox (that kindly does not even provide the helper application the full url (this is covered by another firefox bug)). Another solution: copying the file somewhere? Bad, as for the problem above (impossibility to distinguish when being called by firefox or else) you would end up copying around your document also for normal (non-firefox) usage (imagine to copy a big document in a NFS partition, happiness). As above, I don't think all the kpdf users would be happy for that. > Is it a good policy to depend BOTH on other programs not tampering with the > file on the disk AND on the user not moving or removing the file while viewing > it in kpdf? I would say no. I would say it is better for the program to be > self-reliant, but it is not my decision to make. So, you would say that is better to fix *all* the programs that can be potentially started by firefox, than solving this issue on the firefox side? I would say no.
Thanks again for your time. "so just forget that bug and concentrate on this one, ok?" Ok. :-) "... as already documented in okular's bug 163363." Sorry if that was redundant, I may have gotten carried away. But see below. "> Now, whether this is a kpdf problem or a Firefox problem. > From a user's point of view, it is definitely a kpdf problem. Especially when firefox removes the downloaded files, it happens with any application out there that is started that way." I am not sure I follow. I did really test the exact same scenario (open pdf with pdf viewer, close firefox(/remove file/move file), save pdf) with acroread, and it saved it alright. "They (acroread) can do that as they have no "watch file" function, I suppose. So, if you choose to watch your documents for changes, keeping the file open breaks this feature (and I think that the users of that would not be happy)." This is an aspect I admit I've not considered thoroughly. However, when I open a file, I consider that (the open file in the application) as "the reference" that I am working with, and if the data on the hard drive changes, I don't expect the already once opened data that I am working with to pick up those changes, unless directed to re-load the file. One question here - would it be fair to compare kpdf with an image editor or a text processing application? (In the latter, (as far as I am aware) "what the user is working on" is generally the "copy" held by the program (in memory), not directly the data on the hard drive.) Or is this radically different, because kpdf is for viewing, while the others are for modifying? (I.e. whether the latter are *expected* to *maintain* the data on their own, while a viewer (kpdf or e.g. an image viewer with no editing capability) is only expected to *show* it?) "Another solution: copying the file somewhere? Bad, as for the problem above (impossibility to distinguish when being called by firefox or else) you would end up copying around your document also for normal (non-firefox) usage (imagine to copy a big document in a NFS partition, happiness)." I think I see your point, or at least half of it. Copying to memory only then? I can see it being inefficient memorywise (although swap would take care of the "copying" if copying to disk is needed), but... there also seem to be downsides to not doing it. If I understand correctly, that's what acroread seems to do. But what happens with HUGE files, exceeding memory+swap? I admit, I don't have all the answers. "So, you would say that is better to fix *all* the programs that can be potentially started by firefox, than solving this issue on the firefox side?" Fixing it in Firefox would definitely help, but unfortunately the issue isn't limited to that. If we exclude any other programs that might interfere (I'm not saying they will, but kpdf will be explicitly relying on them not to), there's still the user, who can manually move files around or remove them, bringing up this problem.
I want this bug fixed too. I remember deleting pdf file myself because I had kpdf with that file open. and I was 100% sure I will be able to save it from kpdf. And I couldn't. That was totally unexpected. I expect pdf viewer to be able to save the file it has "open". As a user I agree to loose some other features - e.g "file watching". By the way I have no idea what "file watching" is. I have heard about it in this thread for the first time. In my opinion the best solution would be to let the users choose themselves. Somewhere in configuration dialog there could be a mutually exclusive options: 1. option to watch file (lose option so save deleted file) 2. option to save deleted file (loose option to watch file) I have read that Pino Toscano already had had implemented it. Maybe it would be worthwhile to add this feature again and let the user decide?
No, KPDF it's at the end of it's live, we are only fixing critical bugs like crashes, etc. This is not a critical bug. You can open bugs/wishes about Okular if you want, we are developing this in KDE 4