All users were logged out of Bugzilla on October 13th, 2018

Sessionstore can be cleared if computer crashes

VERIFIED DUPLICATE of bug 477934

Status

()

VERIFIED DUPLICATE of bug 477934
11 years ago
10 years ago

People

(Reporter: volkmarkostka, Unassigned)

Tracking

({dataloss})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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

11 years ago
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.
(Reporter)

Comment 2

11 years ago
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.

Updated

11 years ago
Duplicate of this bug: 392616

Updated

10 years ago
Keywords: qawanted

Updated

10 years ago
Duplicate of this bug: 445675

Comment 5

10 years ago
This is probably due to bug 318156 (the drive cache isn't being flushed after the file's been written successfully).
Status: UNCONFIRMED → NEW
Depends on: 318156
Ever confirmed: true
Keywords: qawanted → dataloss
OS: Windows 2000 → All
Hardware: x86 → All

Updated

10 years ago
Duplicate of this bug: 475179

Comment 7

10 years ago
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 ?
(Reporter)

Comment 8

10 years ago
Î 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

10 years ago
(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...

Updated

10 years ago
Blocks: 123929
Depends on: 477934
No longer depends on: 318156

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 477934

Updated

10 years ago
No longer blocks: 123929

Updated

10 years ago
Duplicate of this bug: 480876

Updated

10 years ago
Duplicate of this bug: 495233
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.