Version: 0.6.3 (using 4.0.4 (KDE 4.0.4), 4.0.4-4.fc9 Fedora) Compiler: gcc OS: Linux (x86_64) release 2.6.25.3-18.fc9.x86_64 When clicking on a PDF link in konqueror from a web site, the document is automatically downloaded to tmp and opened with okular. Later, when you try to save a copy to your home directory, okular responds with the message "cannot save to file:///home/..."
Works here. What is the complete error message?
title: information - okular File could not be saved in 'file:///home/bh/Documents/dwthj4rrfhrf'. Try to save it to another location. buttons: OK actually this does not always happen. It happened to me three time yesterday but cannot produce it just now. I will give you a specific case when I find it again. Thanks for the prompt response
Same problem with kpdf after following a link to a .pdf file in Firefox. I can view the file on the screen, can print it, but cannot save it. The same error message comes up. Strangely enough there is no .pdf file with same name in /tmp.
I can reproduce the problem by opening an url with okular from firefox (iceweasel, for what matters), and then closing the firefox window. It seems firefox removes the temporary downloaded file when closing, thus okular bails out that way. I can add a workaround to make okular downloads the file, in case it is a remote file and the local temporary file is gone. Although, this IMHO is also a firefox bug.
it would be good enough I suppose it okular just tells the user that the file that was opened has been deleted. We cannot expect okular to some how prevent the deletion can we? If okular locks the file for writing then problems will occur when we use it as a preview screen while editing e.g TeX documents (where one recompiles repeated to see changes and just has to refresh in okular instead of having to open it over and over). Another way to solve it might be to keep opened files in swap or a cache, though this does not scale to very large documents (100MB+) as loading times would be terrible.
SVN commit 818136 by pino: Keep an open file handle on the local file currently open: this way, we can get it back from it, in case for some reason (read: Firefox blindly removing temporary files) it gets "deleted". Of course, this works (and thus it is activated) only on UNIX systems (as the file is not deleted for real until there are open handles on it). BUG: 163363 (If not wanted, this behavior can be disabled by export'ing OKULAR_NO_KEEP_FILE_OPEN to 1.) Also, in case the local file gets deleted but the real document is remote, use its (remote) URL for the copy. M +113 -2 part.cpp M +2 -0 part.h WebSVN link: http://websvn.kde.org/?view=rev&revision=818136
For sake of completeness, bug reports against Firefox and its "nice" behaviour: https://bugzilla.mozilla.org/show_bug.cgi?id=437767
SVN commit 818144 by pino: disable the open handle on the file, it breaks the file watching CCBUG: 163363 M +0 -3 part.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=818144
Sadly, I have to reopen the bug, as the solution (well, the hack) conflicts with the file watching. The only solution that Okular can offer in these cases (local file only, that gets deleted) is an error message, sorry. I will add it as soon as I get the permission from the KDE translators. For the general problem, please refer to the Firefox bug linked in comment #7. Thanks for understanding.
The information dialog for informing the user about such situation has been added. As explained in comment #4 and #9, Okular cannot do more about this problem, that has been reported (see comment #7). Thus, closing.
*** Bug 271358 has been marked as a duplicate of this bug. ***