98476 - no redundant backup of critical cfg files (e.g., prefs.js)

Status: VERIFIED FIXED

(Core :: Preferences: Backend, enhancement)

Description

[phoenixreads]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801

This is a general design issue.

Randomly when there is a crash, pref.js along with bookmark.html can get
corrupted and trashed.  Without a redundant backup there is no way to goto last
known good state and one is returned to the installed state.

This has occurred frequently enough that I keep a copy of pref.js so I don't
have to reconfigure my account setting each time there is a crash.

At present, Mozilla returned back to its installed state. 'pref.js' was
corrupted and replaced and bookmark.html was partially retreived.  Without the
precaution and knowledge of recovering corrupted files all data would have been
lost.

Recommedation: Wouldn't it be easier for Mozilla to detect the error and restore
from a previous known good backup?  In most cases, no lost of data will occur
and the end user will be completely unaware an error occurred.  Not to mention
it will allow power user to restore to a previous state.

Comment 1

[Mike Young]

I think this should be a dup of bug 85316

Also, severity should be enhancement. Not marking as dup yet, because someone
might think differently. Please speak up if you do.

Comment 2

[David Illsley]

I don't agree that this is a dupe. What I see this asking for is for moz to make
a backup of critical config files when moz starts and, if the originals get
noticably corrupted, the backups are restored when moz next starts.

Changing Platform PC -> ALL

Comment 3

[phoenixreads]

not a dupe of backing up profiles but system redunacy

David Illsley preception is correct. If I make a change to the pref.js file
there would be two previous saves to restore back to.  

This save -> Last save -> Second last save

This would have enough redunacy that only complete destruction of all three
files would result in return to initial state.  Perhaps you don't use Windoze
but this type of redunancy is required to maintain data. :)  Well at least one
previous saved backup is mandatory.

The file corruption was from a systems crash not Moz and it took those files
with it since Moz was open at the time.
At the moment I lost access to two newsgroups which I added since my last backup
that I might? be able to restore to.  Imagine the "@#)$ piece of ****" response
a typical user would give if that happen more to them more than once?

Comment 4

[Brian Nesse (gone)]

There is currently another bug open against prefs (Bug 94010) to back up the
current prefs.js file before saving the new one. It seems to me that by simply
not deleting that backup you could accomplish this as well. Of course that won't
fix bookmarks...

Comment 5

[David Illsley]

*** Bug 98648 has been marked as a duplicate of this bug. ***

Comment 6

[Greg K.]

Don't the major OS's have some file rescue functionality that can be employed
here? I know Mac OS "rescues" some files open during a crash and puts them in a
special place for retrieval upon restart, and I'd be surprised if Windows and
Unix don't have something similar. Let's try to leverage these systems if
possible instead of writing and depending on yet another Mozilla-only solution.

Comment 7

[Mike Young]

Confirming bug since we have a duplicate. (I though bugzilla was suppossed to do
that for us automatically)

Comment 8

[Ali Hussnain Shah]

i think it happens mostly, when you have an opened bookmark file (file is on the
disk opened physically) while you are surfing and there is a crash. 
i dont know how mozillas code looks like in this case, but responsibles should
check that if user opens the bookmark file in a new windows, dont open bookmarkfile 
for write operations. and open it only when required and close it as soon as
possible as not needed any more.

Comment 9

[Mike Young]

*** Bug 99341 has been marked as a duplicate of this bug. ***

Comment 10

[Matthias Versen [:Matti]]

*** Bug 117345 has been marked as a duplicate of this bug. ***

Comment 11

[Matthias Versen [:Matti]]

*** Bug 117348 has been marked as a duplicate of this bug. ***

Comment 12

[George Mitchell]

Hopefully the developer(s) assigned to deal with this problem carefully review
all the duplicate reports coming in (I just submitted two) because there are
some nuances here that are not readily apparent by working from any one
submission.  Although I would agree that this is an enhancement request, it is
not a typical enhancement request, in that the lack of this feature has a
devastating effect not only on the browser, but on Mozilla Mail as well.  It
should be an enhancement of the highest priority and the fix should perhaps
function similarly to Open Office, where the user is prompted on start up to
retrieve the lost config data.  An ideal time to create the backup(s) is when
the user changes their preferences since that assumes that the system is sane at
the time and that new backups need to be made.

Comment 13

[Brian Nesse (gone)]

The issue of validating and restoring from backup poses some additional 
challenges and is also somewhat dependent on seperating preferences from the 
JavaScript engine. I am going to leave addressing those issues for the more aptly 
titled bug 123027 (verifier for prefs.js). I will address the redundant backup 
issue here.

Comment 14

[Brian Nesse (gone)]

Attachment: Proposed patch

This patch adds safe saving support (fixes bug 94010) as well as support for
multiple redundant backups. The number of backups defaults to 1, but can be set
by the user to any number they feel is appropriate for them (including 0 ;).)

Comment 15

[Simon Fraser [no longer active]]

Comments:

+
+        nsIFile *GetSaveFile(nsIFile *aTargetFile, PRInt32 aNumBackupCopies = 
0);

State what the ownership model is for the returned nsIFile*. It should probably 
be an addreffed out-param.

+nsSafeSaveFile::nsSafeSaveFile(void)
+ : mTempFile(0),

No need to init mTempFile; it's an nsCOMPtr and will take care of itself.

+   fileName(0),

ditto.

+   mTargetFileName(0),

init with nsnull.

+nsIFile *nsSafeSaveFile::GetSaveFile(nsIFile *aTargetFile, PRInt32 
aNumBackupCopies)

Shouldn't these params be passed to the ctor? It seems that they are data that 
the class needs to operate.

+    // remove the file as determined by the logic above
+    backupFile->Exists(&bExists);
+    if (bExists)
+        backupFile->Remove(PR_FALSE);

Why bother with the Exists test; Remove will just fail, but that's OK.

+  tempFile = safeSave.GetSaveFile(aFile, numCopies);

Whoops, now your refcounting just got screwed. You'll do an extra release on this 
nsIFile no?

+  // TODO: Convert the rest of this code to nsIFile and avoid this conversion to 
nsIFileSpec

Can't you do that in this page? All you need is an output stream....

Comment 16

[Simon Fraser [no longer active]]

s/this page/this patch

Comment 17

[Brian Nesse (gone)]

>Shouldn't these params be passed to the ctor? It seems that they are data that
>the class needs to operate.
Initially I did this. Then I changed my mind. I can change it back...

>Whoops, now your refcounting just got screwed. You'll do an extra release on
> this nsIFile no?
Hmm, well I didn't notice a problem when I stepped through it, but I could have
missed it...

>Can't you do that in this patch? All you need is an output stream....
I started doing that once. Found the way the data was being streamed out didn't
appear to allow for an easy conversion to an nsIOutputStream. I will look at it
again.

Comment 18

[Brian Nesse (gone)]

Attachment: Revised patch

New, much larger :), patch addressing comments from sfraser and alecf.

Comment 19

[Alec Flett]

Comment on attachment 68384 [details] [diff] [review]
Revised patch

- after talking with brian and giving him mediocre string advice, we decied to
go with const char * instead of this crazy nsACString& thing that I originally
suggested :)
- mTargetFileName could be an nsXPIDLString
- seems like PostProcessSave() should return an nsresult..specifically the
failure of any of the nsILocalFile calls...esp. the last one (MoveTo()) and
then propagate that error all the way through nsPrefService::savePrefFile()

Comment 20

[Brian Nesse (gone)]

Attachment: Re-revised patch

Yet another patch addressing alecf's additional comments and splitting
nsSafeSave out into its own file (which he also requested, but forgot to put in
his comments.)

Comment 21

[Simon Fraser [no longer active]]

Only nits left:

+  const char *              outHeader = "# Mozilla User Preferences" 
+                                        NS_LINEBREAK 
+                                        "// This is a generated file!" 
+                                        NS_LINEBREAK 
+                                        NS_LINEBREAK;

If you want const data, and not just a const pointer, use
  const char outHeader[] = "";

+nsresult nsPrefService::savePrefFile(nsIFile* aFile)

Not you, but since when did we recomment leading lower case method names?

+  PRInt32 numCopies = 1;
+  mRootBranch->GetIntPref("backups.number_of_prefs_copies", &numCopies);

Does 'GetIntPref' really not touch the param if it fails?

+    temp = strrchr(mTargetFileName, '\.');

Does the '.;' really have to be escaped?

I think this code needs to be very thoroughly tested, including under conditions 
of low disk space (there's a DiskFiller tool for Mac that is useful here). I'd 
also like to know whether the prefs file is saved during startup, since this 
could hurt our startup time. 

Comment 22

[Brian Nesse (gone)]

>Not you, but since when did we recomment leading lower case method names?
This seemed to be the convention that the original prefs files were using to 
indicate a non-public method. I continued to use it, but I'm not particularly 
tied to it.

>Does 'GetIntPref' really not touch the param if it fails?
None of the prefs functions touch the out param if they fail. Many consumers of 
preferences count on this functionality.

>I'd also like to know whether the prefs file is saved during startup, since
>this could hurt our startup time.
The file is saved on startup if the initial read fails (i.e. it does not exist), 
otherwise it is not.

Comment 23

[Simon Fraser [no longer active]]

Comment on attachment 68442 [details] [diff] [review]
Re-revised patch

sr=sfraser. Test, test and test again. This is critical functionality.

Comment 24

[Alec Flett]

Comment on attachment 68442 [details] [diff] [review]
Re-revised patch

excellent. with simon's nits, r=alecf

Comment 25

[Brian Nesse (gone)]

Attachment: A more user friendly patch

This patch addresses the previous nits, and adds two useful methods to
nsSafeSaveFile. One to remove the temp file if the save failed for some reason
(i.e. disk full), and one to delete the oldest backup file. These functions
allow the consumer to detect a failed save, remove the most dated backup, and
retry the save if they are so inclined.

I have tested this functionality, though it is not actually used in the patch.

Comment 26

[Brian Nesse (gone)]

Attachment: Same patch...try again

The last one didn't post correctly... trying again.

Comment 27

[Brian Nesse (gone)]

Attachment: Patch to make the prefs dialog gracefully handle the save error

Some additional Front-End UI changes to make the Preferences dialog recover
gracefully if a save error occurs.

Comment 28

[Alec Flett]

Comment on attachment 69087 [details] [diff] [review]
Patch to make the prefs dialog gracefully handle the save error

sr=alecf

Comment 29

[Alec Flett]

Comment on attachment 68659 [details] [diff] [review]
Same patch...try again

sr=alecf

Comment 30

[Simon Fraser [no longer active]]

Comment on attachment 68659 [details] [diff] [review]
Same patch...try again

r=sfraser

Comment 31

[Simon Fraser [no longer active]]

Comment on attachment 69087 [details] [diff] [review]
Patch to make the prefs dialog gracefully handle the save error

r=sfraser

Comment 32

[Brian Nesse (gone)]

Fix checked in.

Comment 33

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

2 pieces of bustage on Seamonkey-Ports:

On OS/2:

E:/OS2_2.40_Clobber/mozilla/modules/libpref/src/nsSafeSaveFile.cpp(61:30) :
error EDC3054: The "-" operator is not allowed between "char*" and "nsXPIDLCString".

on nebiros:

"/builds/tinderbox/SeaMonkey/SunOS_5.7_Clobber/mozilla/modules/libpref/src/nsSafeSaveFile.cpp",
line 59: Error: Cannot assign const char* to char*.

along with the warnings:

"/builds/tinderbox/SeaMonkey/SunOS_5.7_Clobber/mozilla/modules/libpref/src/nsSafeSaveFile.cpp",
line 60: Warning: The variable temp has not yet been assigned a value.
"/builds/tinderbox/SeaMonkey/SunOS_5.7_Clobber/mozilla/modules/libpref/src/nsSafeSaveFile.cpp",
line 95: Warning: fileName hides nsSafeSaveFile::fileName.
"/builds/tinderbox/SeaMonkey/SunOS_5.7_Clobber/mozilla/modules/libpref/src/nsSafeSaveFile.cpp",
line 155: Warning: fileName hides nsSafeSaveFile::fileName.

Comment 34

[Brian Nesse (gone)]

Had to back out changes due to unexplained orangeness on btek and comet. 

May be related to dbaron's comments. re-opening.

Comment 35

[Brian Nesse (gone)]

Attachment: Patch to clean up ports builds.

I generated this patch in conjunction with dbaron as an attempt to clean up the
issues that showed up on the 2 ports tinderboxen. I suspect that the orange we
saw may also have been due to these same issues showing up at runtime.

Comment 36

[Alec Flett]

Comment on attachment 70184 [details] [diff] [review]
Patch to clean up ports builds.

sr=alecf

Comment 37

[Simon Fraser [no longer active]]

Comment on attachment 70184 [details] [diff] [review]
Patch to clean up ports builds.

r=sfraser

Comment 38

[Alexey Chernyak]

Question: You mentioned removing oldest backup on save fail. Will it be possible
to lose *all* backups this way through repeated save failures?
Under low disk space conditions, you should not relay on deleting backups for
recovering free space, because as soon as you free up some space, something
else, other than Mozilla might claim it.

Comment 39

[Brian Nesse (gone)]

There is no automatic removal of backups. I added the ability for the consumer
to remove the oldest backup if they so choose. This will not happen unless
called PurgeOldestBackup() is specifically called by the nsSafeSaveFile consumer.

Comment 40

[Brian Nesse (gone)]

*** Bug 127942 has been marked as a duplicate of this bug. ***

Comment 41

[Matthias Versen [:Matti]]

*** Bug 128131 has been marked as a duplicate of this bug. ***

Comment 42

[Jaime Rodriguez, Jr.]

nsbeta1+ per ADT/Embed triage.

Comment 43

[Alexey Chernyak]

*** Bug 128879 has been marked as a duplicate of this bug. ***

Comment 44

[Chris Lyon]

*** Bug 131105 has been marked as a duplicate of this bug. ***

Comment 45

[Chris Lyon]

*** Bug 122362 has been marked as a duplicate of this bug. ***

Comment 46

[Ian Webb]

I posted Bug 131105, which concerns loss of only bookmarks added during the 
current session when Mozilla crashes. It was marked as a dupe of this bug, but 
it doesn't seem to be a dupe, unless I'm fundamentally misunderstanding this 
bug. This bug, along with the other bugs marked as dupes of it, discusses loss 
of bookmarks.html, but this isn't losing the whole file -- the file only loses 
those bookmarks added during the current session. This *might* be an 
unintentional side effect of a fix for 98476, if the file is just being 
restored from a backup. There doesn't seem to be any reason to hold 
bookmarks.html open after writing to it, though, and closing the file 
immediately after writing a new bookmark to it ought to address this.

Since 131105 was marked as a dupe of this bug, I'm posting this here.

Comment 47

[Brian Nesse (gone)]

Ian, you are correct that this bug has nothing to do with bookmarks.html.
Although the code in this patch could be used to help fix bookmark issues, the
landing of this patch will in no way do so.

Comment 48

[Vadim Berezniker]

is this bug still supposed to be reopened?

Comment 49

[Brian Nesse (gone)]

Yes. I still need to figure out what it is doing that causes the tinderboxen to
go orange when I land it.

Comment 50

[Michael Lefevre]

*** Bug 135615 has been marked as a duplicate of this bug. ***

Comment 51

[Michael Lefevre]

not going to mess with the summary on an established and assigned bug, but I'd
suggest that adding something about lost prefs/bookmarks to the summary would
make this easier to find.

bugs duped against this:
"All bookmarks/prefs/saved data GONE", "Browser configuration data lost",
"Mozilla-mail config files lost on power failure", "Preference file nuked", "All
bookmarks lost after computer crashed while managing", "intermittent total loss
of prefs", "bookmark file corrupted"

Comment 52

[Alexey Chernyak]

Another thing that I found to be lost on crash is browser History, on which I do
rely heavily for URL autocompletion.

Comment 53

[Matthias Versen [:Matti]]

*** Bug 143158 has been marked as a duplicate of this bug. ***

Comment 54

[Susie Wyshak]

To summarize my duped bug:
1. Bookmarks and toolbar shortcuts deleted
2. History is intact and prefs.js looks ok too on a quick glance
3. Can't drag fave icon onto toolbar anymore to add shortcuts 
(in the profile which had the files deleted)

Comment 55

[Cameron Simpson]

Just read Brian Nesse's patch in comment #18.
Right at the end it has the action:

    mTempFile->MoveTo(0, mTargetFileName);

In short, having shuffled the backups, _move_ the fresh temp file in
place of the extant config file.

Now, there are two main schools of thought on replacing files: the one above,
which makes a new file, then if ok deletes the old and moves the new in on top,
and the school which says backup the old, rewrite the extant file, then if ok
delete the backup.

I am in the latter camp.

Why? Because the former breaks the extant file's permissions and other state.

Example: I keep most of my config files "off to the side", in an "rc" subdir
of my home dir, for handy access and ready mirroring between work/home/isp. For
many apps it's enough to symlink the app's ~/.foo dir into ~/rc/foo, but that
only works for directories. For plain files on must either symlink or hardlink
from the app's expected path (eg ~/.mozilla/weirdchars/prefs.js) to the master
copy (eg ~/rc/mozilla/prefs.js).

The delete master and rename temp approach breaks that association.

Example two. My usual umask is 077 ("private file access by default" for nonUNIX
people). Now, suppose I make my prefs.js or some other file publicly accessable
for some reason (eg as an example for others). The delete/rename approach will
make a new, private, file. Undoing my altruism.

The core issue here is that there may be arbitrary policy on the user's end
about whatever file you're rewriting, and the delete/replace method destroys it.
All you're doing is replacing the file's content. Therefore, you _should_not_ be
doing things which affect more than the content.

I have met camp 1 (delete/replace) people who, on being presented with this
argument, went and wrote symlink-following, permission reading and restoring,
workarounds. Not only do such things not work (they won't help hard linked
files, they won't help files with nondefault owner/group, etc), they're also
unnecessary bloat totally unsuitable to a function whose core purpose is simply
safe file content replacement.

In summary, this short rant is a request to recast the code to something like this:
    make backup (shuffling old backups as at present)
    rewrite original (ie _just_ open for write/truncate and go)
    if ok delete backup (or not, if you're accomodating change reversion)
    if not ok, rewrite original from backup
      if not ok, delete original, rename backup
        if not ok, complain loudly, citing location of backup for user manual
recovery

Your call of course, but I strongly feel that people should avoid approaches
which assume they know the user's policy, especially since the user lacks an
standard public API for exporting that policy to the app, and also since the
apps really doesn't need to know such policy if cautiously coded.


    

Comment 56

[Brian Nesse (gone)]

*** Bug 145556 has been marked as a duplicate of this bug. ***

Comment 57

[Jaime Rodriguez, Jr.]

When can this land on the trunk, and be verified?

Comment 58

[Brian Nesse (gone)]

There is an interaction between the safe save code and the tinderbox testing
scripts which causes any tinderbox running tests to go orange when this patch is
landed. Until this can be sorted out, this patch can not be landed.

Comment 59

[Jaime Rodriguez, Jr.]

Pls land this one on the trunk, and have it verified, after resolving tinderbox
issues.

Comment 60

[Brian Nesse (gone)]

My current intention, which should make Cameron happy :), is to re-architect the
safe save process along the lines of Cameron's suggestion. A side benefit of
this approach is that the actual process for writing the file will be
essentially unchanged from its current functionality which should eliminate the
Tinderbox script conflict.

Comment 61

[William Kirkpatrick]

I don't see it mentioned here, so don't forget the password manager.  A disk
full error is death, to everything it seems.  "Enhancement" doesn't quite
capture my sentiments right now, as I'm still finding de-config'ed nonsense an
hour after the fact.

Comment 62

[Brian Nesse (gone)]

Attachment: Revised patch based on Cameron's comments

Version which copies current to backup instead of writing temp files.
Additionally, I will also attach nsSafeSaveFile.cpp & h because it is simpler
to look at the entire file(s) than it is the diffs.

Comment 63

[Brian Nesse (gone)]

Attachment: nsSafeSaveFile.cpp

Comment 64

[Brian Nesse (gone)]

Attachment: nsSafeSaveFile.h

Comment 65

[R.K.Aa.]

*** Bug 147053 has been marked as a duplicate of this bug. ***

Comment 66

[jag (Peter Annema)]

Comment on attachment 84976 [details] [diff] [review]
Revised patch based on Cameron's comments

r=/sr=jag

Comment 67

[Alec Flett]

Comment on attachment 84976 [details] [diff] [review]
Revised patch based on Cameron's comments

r=alecf

Comment 68

[Brian Nesse (gone)]

Orangeness fix verified on tinderbox yesterday by mcafee. Fix checked into trunk.

Comment 69

[Jaime Rodriguez, Jr.]

Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.

Comment 70

[Jaime Rodriguez, Jr.]

rvelasco - can you pls verify this on the trunk? thanks!

Comment 71

[Rodney Velasco]

after talking with brian about this he gave me some insight as to how to verify
this bug.  

"what I did for my purposes was to go and edit prefs... hit save/ok and then
compare the contents of the js and bak file... you should see the previous prefs
in .bak and the current ones in .js.  That should be proof that it has done the
right thing"

I couldn't find a test case that would corrupt my prefs.js via crash, so I had
to test to see if the prefs.bak file was writing the correct values on exit of
the browser.  On a File -> Exit or Ctrl-Q prefs.js writes the modified prefs
back to the prefs.bak file. which is what we want because that was the last
known good state. 

In the event of a crash and a corruption occurs the end user should be aware of
reverting back to there old state by renaming or copying the prefs.bak to
prefs.js and load the browser with it's previously known good state. 

Brian also stated you can use the pref("backups.number_of_prefs_copies", 3) to
keep multiple copies of the modified prefs.js file to avoid overwriting your
backup data with the corrupted one. Just add that line to the all.js to create
multiple backups of the prefs file prefs.bak1, prefs.bak2, etc, etc. With that
said...

verified on trunk:
Linux 2.4.7-10
Windows XP Pro
Mac OS X.1.3
Mac OS 9.2.2

Comment 72

[Jason Gilbert]

That's a very handy hidden pref.  Are there others?  How would you do that with
the bookmarks file?

Comment 73

[Andrew Hagen]

>In the event of a crash and a corruption. . . the end user should be aware of
>reverting back to their old state by renaming or copying the prefs.bak to
>prefs.js and load the browser with its previously known good state. 

Doesn't this mean that a user will have to manually move files around in the
event of a crash, or risk profile corruption?

If there is a crash, we should automatically restore the last known good config
files. Unfortunately, this process will sometimes fail because there will be no
known good config files. When that happens, we should restore the config files
to their default settings, just as they are with a new profile. 

Thank you, Brian Nesse and other developers, for your work. 

Comment 74

[Ken Beal]

Rodney Velasco wrote:

>On a File -> Exit or Ctrl-Q prefs.js writes the modified prefs
>back to the prefs.bak file. which is what we want because that was the last
>known good state.

I'm not a Mozilla developer, so I'm not sure if I'm reading into this right, but
shouldn't it save the prefs as soon as the user exits the Preferences dialog? 
Why should there be ANYTHING for it to write out at exit (or crash) time?

What am I missing?  Thanks.

Comment 75

[Brian Nesse (gone)]

Ken, preferences *are* saved when you hit OK in the preferences dialog. But other 
things are also saved in preferences, which are not directly affected by the 
prefs dialog... these will only be saved if preferences are saved on exit.

Comment 76

[Jaime Rodriguez, Jr.]

adt1.0.1 (on ADT's behalf) for checkin to the 1.0 branch. pls check this in
asap, then add the "fixed1.0.1" keyword.

Comment 77

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 78

[Brian Nesse (gone)]

Checked in to the 1.0 branch.

Comment 79

[Rodney Velasco]

Verified on commercial branch
Linux 2.4.7-10 2002-06-20-06
Mac OS 9.2.2 2002-06-20-05
Mac OS X.1.5 2002-06-20-05
Windows 2000 2002-06-20-08

Comment 80

[Susie Wyshak]

I have a few questions that would be helpful to document for future generations
in one comment...so anyone who crashes can refer to this bug to make sure the
fix is working as expected in the real world:

Overall, please describe the user experience when they restart after a crash
other than the fact that only the last saved prefs will be intact. 
-Will they see a popup message about this? 
-Will they have to manually move files around in the event of a crash as asked
in comment #73?

(separate question: Are there any secret ways to recover an old bookmark file
that was completely wiped out due to crashes in previous builds? )

Thanks!

Comment 81

[Robert J. Berger]

I just had a similar crash running the 6/16/2002 build under Mac OS X 10.1.5 on
a G4 Powerbook.

Wiped out (reset to distribution) my Bookmarks, no backup file around. It
doesn't look like it particularly wiped out my preferences as they seem pretty
much there.

There was no warning that it was lost.

Interestingly it wasn't exactly a crash. I had been changing the smtp server for
a mail account and discovered I could not save the preferences. It complained
about the tempoary file not being there. So I quit Mozilla and there were no
warning signs, dialog boxes or anything unusual. When I restarted everything was
fine except my bookmarks were gone.

This may be another bug, but it also applies to the desire to have a more robust
backup mechanism for bookmarks.

Comment 82

[Brian Nesse (gone)]

>Overall, please describe the user experience when they restart after a crash
>other than the fact that only the last saved prefs will be intact. 
>-Will they see a popup message about this? 
No, the PrefService has no knowledge that the Application crashed.

>-Will they have to manually move files around in the event of a crash as asked
>in comment #73?
Yes, see comment above.

>(separate question: Are there any secret ways to recover an old bookmark file
>that was completely wiped out due to crashes in previous builds? )
I don't know anything about bookmarks. Try asking in bug 131105 which pertains
to bookmark dataloss on crashes.

Comment 83

[David A. Cobb]

Re: Comment#80 (Susie)

> Overall, please describe the user experience when they restart after a crash
> other than the fact that only the last saved prefs will be intact. 
My issue was rather with RULES.DAT and with the .MSF files.  Damaged .MSF files
are sometimes not detected and they reflect bad information in the mail
summaries.  The only solution I've found is to exit Mozilla and delete the .MSF,
forcing a re-build.
Damage to RULES.DAT is an even bigger pain.  I've experienced several cases of
damage that completely disabled the mail-filtering function.  For me, that dumps
about 2000 messages per day into my Inbox.  There is no reasonable repair
procedure, it requires going back to a saved version and discovering what
filters need to be recreated.

>  -Will they see a popup message about this? 
No message.  Mozilla doesn't really seem to notice the damage.

> -Will they have to manually move files around in the event of a crash as asked
> in comment #73?
As stated, restore is from a home-grown Zip archive of selected files.

> (separate question: Are there any secret ways to recover an old bookmark file
> that was completely wiped out due to crashes in previous builds? )
Back it up yourself, manually, as I've been doing. ;=P

Comment 84

[R.K.Aa.]

*** Bug 158501 has been marked as a duplicate of this bug. ***

Comment 85

[Bill Mason]

*** Bug 170460 has been marked as a duplicate of this bug. ***

Comment 86

[Peter Toneby]

I lost my bookmarks-file today while surfing http://www.ageofmythology.nu/ and
clicking "Prizes & Rules" mozilla crashed, most likely it was Flash that caused
the crash.

I didn't lose prefs.js or my history.

I didn't have any backups of the bookmarksfile. Shouldn't I have at least one? I
added one bookmark during the session.

I didn't have backups.number_of_prefs_copies set, I've set it to 3 now, since
this isn't the first time I've lost my bookmarks due to crashes.

I'm using Build: 2002111605