Version: 3.5.9 (using 3.5.9, Gentoo) Compiler: Target: x86_64-pc-linux-gnu OS: Linux (x86_64) release 2.6.25-gentoo-r7-20080501 The distinction between /tmp and /var/tmp is one of persistence. Stuff which should persist across reboots is supposed to go in /var/tmp while /tmp is for stuff that would do perfectly well on volatile storage like a RAM drive. Given that a full-system crash or a power outage will necessitate a reboot, putting recovery journals in /tmp is a bad idea. Some distros, Gentoo included, default to wiping /tmp on boot rather than shutdown and I've been bitten several times by that. Even if a distro wipes /tmp on shutdown, there are many types of problems which would induce a novice user to reboot rather than attempting to resuscitate X11. I've actually resorted to using Firefox for important browsing sessions just because of this problem.
Changed severity to "crash". I hope to have selected only the right bugs (>100) :-)
Crash log is generated by either the system (core-dump files) or drkonqi if a dialog pop ups to show the crash. As such this has nothing to do with konqueror. Konqueror does not save crash log files and saves all other essential non-transient information under /var/tmp/kde-<username> ; so I have no idea which crash file you are specifically refering to here. If you are talking about the generated backtrace files, then you have to report this issue against drkonqi and not konqueror.
Reassigning...
DrKonqi doesn't save anything anywhere. It can optionally save the backtrace to a text file, but in this case it pops up a file dialog allowing you to choose where to save it. So, what crash logs are we talking about here? PS: looks like this bug report is ancient... drkonqi has been rewritten since then, but iirc the kde3 version also didn't save anything anywhere as well.
This isn't a DrKonqi issue. In retrospect, I wasn't clear enough. I'm referring to the logs of tab-opening and closing which Konqueror writes so that it can use them to restore browsing sessions interrupted by a crash.
Assign this back to konqueror based upon comment #5.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
I don't remember how I located Konqueror's session-recovery logs back in 2008 and I can't find them now. Since I don't currently have time for the nuclear option of spinning up a VM, crashing Konqueror, emptying /tmp, and seeing if it still offers to recover my tabs, I have no feasible way to check if this still applies. (If Konqueror is still writing session-recovery logs to /tmp, then it's still a problem. Otherwise, it's not.)
Thanks for the update!