569683 - prefs.js file and possibly some other file are sometimes lost if the computer is shut down brutally directly from the power switch!

Status: RESOLVED DUPLICATE of bug 415910

(Core :: Preferences: Backend, defect)

Description

[Tapio Angervuori]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.4

If SeaMonky looses the prefs.js file it can not do anything next time it is opened! You must recover the prefs.js file from the backup disk or install the whole program again!

SeaMonkey should keep backup copies of all the vital files that are open during the program is active, so that in case of a lost file, it could directly use the backup versions of them! 

Reproducible: Always

Steps to Reproduce:
1.Delete the prefs.js
2.Star the SeaMonkey
3.Everything has to be reconfigured!
4. Copy back the prefs.js
5: Everything is OK again!

Comment 1

[WADA:World Anti-bad-Duping Agency]

Attachment: Process Monitor log for prefs.js update on MS Win

prefs.js update looks similar to next.
1. write to prefs-1.js, 2. delete prefs.js 3. rename prefs-1.js to prefs.js
Developers probablly calls it "Safe file writing".
As seen in process monitor log, "step 2 and step 3" consists of multiple internal steps. So, loss of both prefs-1.js and prefs.js can happen within "step 2 and ste 3", if power failure or system crash happens.

Comment 2

[WADA:World Anti-bad-Duping Agency]

Following is a way for safer file writing.
(A) improvement of "safe file writing" 
A-1. delete prefs.js-old
A-2. write prefs-1.js
A-3. rename prefs.js to prefs.js-old
A-4. rename prefs-1.js to prefs.js
A-5. delete prefs.js-old
(B) Safer writing of prefs-1.js.
B-1. Write indicator of write in progress.
B-2. Write all data in prefs-1.js.
B-3. Write indicator of write completes.
indicator of "write in progress" can be 0x00 at offset 0 instead of first byte.
indication of "write completes" can be replace of the 0x00 by first byte of real prefs data at offset 0.

Comment 3

[WADA:World Anti-bad-Duping Agency]

See bug 415910, please. AFAIK, it's only bug which points problem in current "safe file writeng".

Comment 4

[Philip Chee]

Moving to Core::Preferences Backend.