Version: 0.5.81 (using KDE 4.5.85) OS: Linux I thought I had already reported this, but I could not find it. Okular should not try to load files stored in tmp-directory on session-restauration. Files in the tmp-directory are deleted on reboot, so Okular will not find them and give error messages. This is really annoying. Reproducible: Always OS: Linux (i686) release 2.6.37-7-generic-pae Compiler: cc
Let me guess, were those documents open from firefox/iceweasel?
I need to test this, but Firefox is my main browser. But I also requently open PDF which I receive via Kmail and I am quite sure (need to test) that those are affected too.
I have tested: It affecteds PDFs opened from Kmail (KDE PIM 4.4.8 in KDE 4.6 Beta 2), PDFs opened from Firefox and PDF openend in Konqueror which can not be downloaded again (Bankstatements).
If it takes more time to find a solution, it would at least help, if the error message would be turned into a notification, so that I do not have to click them away.
I really don't see what we can do here, you opened a file and then someone else deleted it. And then you restarted the session so we tried to go back to where we were, but failed to open the file since its gone. And we tell you about it. As far as i can see all steps are correct. It is you that know that files in *your* /tmp are volatile, but in mine they might not.
I have not done anything with my temp file. But as far as I know Kmail delete attachments which are remporarily saved in /tmp when opened after closing of Kmail for security reasons. I assume Firefox may have similar reasons for doing that. And both makes sense.
Noone says it does not make any sense, i'm just asking what we are supposed to do. We are restoring the previous state so we try to open the files and the files are not there, so it fails.
Hmm. from my opionion the easiest would be: No session restauration in the /temp directory, but you do not seem to like that. Or to make this a configurable option. May be a solution could be: Do not show error message (and empty okular instances) if a file in /tmp could not be restored. Alternative: Make this optional. I don not know if I am wrong, but as I see it, the likelyhood of a file being there when it was opened in /tmp is very small unless someone saved it there manually. So the third option seems the best.
I'm sorry, but i disagree. Moving your report to wish since i fail to see any problem in Okular behaviour.
:-( Sounds like it means wontfix too or would you consider implementing something which solves this problem. Do you really see no problem if a user as say four Okular windows poping up saying the file could not be opened? Another possibility could be to turn popup windows into notifications (which a user can turn of) and close the okular instance again.
Yes, it basically means wontfix unless you can find thousands of people that back your wish and then i might reconsider it. No, i don't see a problem in trying to reopen a file you previously had opened and telling you we failed to do so. Automatically closing okular is bad since you'll see it appear, and then disappear leaving you with a big "wtf" inside your mind.
Can you still reproduce the issue with some newer version?