406378 - Sessionstore can be cleared if computer crashes

Status: VERIFIED DUPLICATE of bug 477934

(Firefox :: Session Restore, defect)

Description

[Volkmar Kostka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120105 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b2pre) Gecko/2007120105 Minefield/3.0b2pre

Lately my computer reboots without notice. After startup minefield starts without any tabs from sessionstore. The last bak file was at least one start old and the .js file was empty.
This leads to the conclusion that the sessionstore file can be damaged/removed if the system crashes.
I suggest using a round-robin of at least two files to get a more recent saved state if the last one was removed or damaged during a system crash.

Reproducible: Sometimes

Steps to Reproduce:
System has to crash/reboot unexpected e.g power loss
Actual Results:  
Minefield sometimes starts without any tabs. Session is not restored.

Expected Results:  
Minefield should start with the offer to restore session.

Comment 1

[Simon Bünzli]

Volkmar: Have you experienced this issue ever again (possibly with a release version of Firefox)? sessionstore.js is actually saved in two steps, which should ensure the file's integrity. It should especially never be completely empty as you suggest above.

Comment 2

[Volkmar Kostka]

It is hard to reproduce it. I never saw it again using normal shutdown.
Maybe i'll try to reproduce it on my laptop which runs FF 3.0. Switching a running computer is not recommended on a production system.

It is probably impossible to control the exact behaviour of the drive cache. Maybe the js file was still in the drive cache and was not flushed after creation so the file was not really written to the platters.

Comment 5

[Simon Bünzli]

This is probably due to bug 318156 (the drive cache isn't being flushed after the file's been written successfully).

Comment 7

[Benoît Dejean]

Moreover, i don't get where was the previous session store in my case. I started firefox, restored a previous session (not because of crash) and then got a power cut. When i got back, the .js was empty but the .bak is 20 days old, i.e. it's not the session i previously restored. Where has it gone ?

Comment 8

[Volkmar Kostka]

Î have a similar problem with a project i currently work on. In this case the store has to be bulletproof.
It is done by *not* removing the previous file unless it is sure that the last one was successful saved.
If you can not guarantee that the file system was updated on the disc keep unto N recent files. This should not too complicated.

Comment 9

[Simon Bünzli]

(In reply to comment #7)
For Firefox 2.0 and 3.0, we've only backed up crashed sessions (to prevent dataloss in case a session crashes before you can close the crashy tab). Starting with Firefox 3.1, the backup will always be of the last restored/resumed session.

Until you update to Firefox 3.1, you might want to install the Session Manager extension from <https://addons.mozilla.org/firefox/2324> which will automatically create as many backups as you want.

(In reply to comment #8)
> It is done by *not* removing the previous file unless it is sure that
> the last one was successful saved.

We already do that. As you can see, if you don't also flush the file system's lazy-write cache, it doesn't buy you much...

> If you can not guarantee that the file system was updated on the disc
> keep unto N recent files.

Even with a reasonably big N, this will just improve the _chance_ that at least one of those files is actually written to disk. Fixing bug 318156 shouldn't be that much harder and is the Right Thing to do. Patches are welcome...