Closed Bug 170539 (prefs_lost) Opened 22 years ago Closed 22 years ago

prefs.js gets wiped - all mail/news accounts settings lost

Categories

(Core :: Preferences: Backend, defect)

Product:
Core
Component:
Preferences: Backend
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.3final

People

(Reporter: boblists, Assigned: ccarlen)

References

Details

(Keywords: dataloss, qawanted, Whiteboard: fixed1.3)

Attachments

(2 files, 1 obsolete file)

prefs.js related activity at Mozilla shutdown as reported by FileMon
(deleted), text/plain
Details
patch v2
(deleted), patch
dveditz
: review+
alecf
: superreview+
asa
: approval1.3+
Details | Diff | Splinter Review 
I booted up my machine and went to check my mail one day and all the accounts
and everything had disappeared. prefs.js turned out to have been wiped.

tvujmejl.cz@mujmejl.cz - (Daniel Hrbac) told me on the mail-news group that this
was caused by quickstart, so I've stopped using that.

There are several reports of this bug up on the newsgroup - I feel that it is
very serious if you have a lot of accounts set up.

I will not be able to recommend that people use Moz mail untill this is fixed.

I am happy to do any testing required etc.

Russell
a) ALWAYS add the build ID in a bug report
b) the quickstart prefs problem is already solved in Mozilla 1.1 and there is a
note in the release notes (for the affected release)
c) We have a file prefs.bak (backup) in recent builds.

Please add more nformations or this bug is invalid

-> Profile Manager Backend
Assignee: racham → ccarlen
Component: Account Manager → Profile Manager BackEnd
Product: MailNews → Browser
QA Contact: nbaca → ktrina
Hi

I had this happen in Mozilla 1.1 - does this count as a build ID?
I can't see any of those long build IDs on this one, but 1.1 is 1.1 right?

My prefs.bak was also wiped - I had to go back to an old backup of prefs.js

Russell
Do you see this only with quicklaunch ?
I was using quicklaunch.

It is a diffucult bug though I guess, because it seems to happen randomly and
quite infrequently.

I've stopped using quicklaunch because tvujmejl.cz@mujmejl.cz - (Daniel Hrbac)
told me on the mail-news group that this bug was caused by quicklaunch. I don't
know if he's basing that on much. I'll try to contact him and see if he has
anything to add here.

It only happened to me once - and it hasn't happened again since I turned it
off, but unfortunately that dosen't tell us much!
Dupe of bug 155080?
bug 155080 should be fixed with 1.1b and 1.1 Final...
also related : bug 171919
I've got a mail back from the chap that said it was quicklaunch. Here it is:

================================================================================

to be honest this happend to me couple of times some time ago. Since I qiut
using quicklaunch there was no reccurence of this bug. When I lost prefs.js I
found a bug (i hope it was in bugzilla) saying it is the matter of quicklaunch.
I can not remember whether it was with mozilla 1.0 or 1.1 (I never installed any
nightly builds). I also cannot remenber the exact source of the information. I
even did not noticed that this bug should be fixed in 1.1. My comment was based
on my experience only, since I noticed couple of reports to the list were made.

I am not any kind of programmer, just a user. If it will help you I can start
using quicklaunch and report you. Do you need to know the config of my PC?


-- 
Daniel Hrbac
tvujmejl.cz@mujmejl.cz 

================================================================================
This problem has happened several times to me in the last 3 weeks on a random
basis and is very frustrating. This needs to be dealt with promptly before
people will comfortably and seriously consider the use Mozilla for email without
worrying about whether they will have to enter their account details every 3 or
4 days. Furthermore, not only does it lose the account details but all the email
as well (ouch!) ...

To be honest I think there is more to it than just quicklaunch ... I logged onto
my PC (Win2K, Moz 1.2b, Build #2002101612) as Administrator and, hey presto, the
accounts which had been "lost" when I logged in as myself were there. Is Mozilla
having problems dealing with multiple accounts on one machine (it shouldn't as
it works fine under Linux)?
> Is Mozilla having problems dealing with multiple accounts on one machine

For each OS account, there is a separate list of mozilla profiles. If you
(1) log on as 1 OS user and create a profile
(2) log on as another OS user

you will not be able to access the profile in (2) which was created in (1).
That's by design and should be the case on Linux as well. On Linux, there is a
separate profile list in each user's home dir.
Mozilla 1.0.1 update

I've been watching out for this bug on 1.0.1 - all good so far, not that that
tells us much.

I've pretty much not been using my desktop Mozilla 1.1 that I observed this in.
I've been using 1.0 then 1.0.1 on my laptop out of fear of this bug since then,
and everything has been much better.

I would really like to know if anyone thinks they have fixed this and what
causes / is causing it. If someone recons they've fixed it at any point I'll
take the risk and upgrade to a more recent version and carry on monitoring this bug.

Russell
There would be two things that would be really great, and might even get the bug
fixed:

1) Download a recent nightly build from www.mozillazine.org, and just start
using it for general use. (They're _pretty_ stable, honestly, but they're not
nearly as stable as real releases. You might want to keep backups of important
stuff.)

2) Search for every bug that you think might be related to this one, even
possibly, and just paste all of their numbers (like "bug ######" without the
quotes) in a comment. I'd do it, but it just takes a lot of time. :-)

-M

(Adding "dataloss")
Keywords: dataloss
Just saw this on Win2000.

I was installing mozilla (1.1) on a friend's computer. Everything went fine for
the install process, but after a few restarts, mail profile and _some_ (not all)
of the preferences were lost. Lauching mail application poped-up the new account
window.

prefs.js was cut back to 528 bytes. Using a backup of this file seemed to solve
the problem, but a few restarts later, it occured again.

I desinstalled mozilla 1.1 (I cleaned mozilla.org manually), and installed the
lastest 1.2-trunk (2002112117). All went fine for a little while, and then lost
happened again.

Quicklaunch was _not_ activated.

I experienced this lost about every five restarts, but sometimes it was OK for
10 times, and sometimes it only take 2 restarts to see the problem.

Using a backup for prefs.js seems to correct the problem when it happens (not
always for the first restart after the "lost", strangely), but after that the
mileage may vary...

Very annoying, as it seems to happen randomly...
1) 1.1 is not a recent build. In fact, it's too old to report bugs against.

2) Did you start with a clean profile? As it says in the Mozilla release notes,
every installation of Mozilla is intended to start with a clean profile.
(Remember, Mozilla is provided for testing, so look to Netscape builds and
others like that for the ability to keep your profile across builds.)

-M
1/ Yes, moz1.1 is not what I call "a recent build". But it is a major release,
and what I described looks like a major bug for me. I was installing 1.1 because
my friend is not a geek, and I didn't want to install bleeding edge software on
his computer. But I didn't report this bug against 1.1, I was just describing
all the steps before I actually hit the bug. This bug occured also in 2002112117
build, which is, I think, a recent build.

2/ I did not see anything in the release notes about not being able to keep the
profiles across builds. As a matter of fact, I've used mozilla myself for about
2 years, pretty intensively, with frequent updates, and I _never_ cleaned my
profile, and I _never_ experienced this bug, or any bug related to profile
management (not very relevant, I know, but I never saw anywhere that it wasn't a
legitimate behaviour to keep the profiles across builds).

What I saw about updating mozilla is that you need to start with a clean
computer (with no previous install of mozilla), which I did, by deinstalling
previous version and manually cleaning the "mozilla.org" directory. The profile
was clean before the first install, and the bug occured anyway, so it doesn't
seem related...

And finally, what do you mean by "mozilla is for testing" ? Are you talking of
releases or nightly builds ?

I know that nightly builds are for testing, and this is just why I reported the
bug : to help correcting it before a non-testing-oriented release, since I find
this bug quite critical...
Actually, all Mozilla.org binaries are for testing only. Netscape and others
release commercial, supported versions.

From the mozilla.org homepage: "Mozilla.org provides binaries for testing and
feedback."

As far as the profile thing goes, I've never cleaned my profile either. But
that's the first thing we reccomend for people experiencing difficulty.

There are a few prefs.js bugs lying around -- I think this one might be a
duplicate of another one. If it isn't, I'll confirm it sometime. If I don't get
around to it, remind me or something. :-)

-M
"Mozilla.org provides binaries for testing and feedback."

OK. I took that part more like a disclaimer than anything else...

Anyway, I have tested, and I am feedbacking :-)

I will try again with fresh profile and update this when done.
Hi All,

I'm a very passionate supporter of Mozilla since years. So please note DRIVERS!

THIS IS THE MOST CRITICIAL MOZILLA BUG I HAVE EVER HEARD TILL NOW.

I made the same experience several times and it is very frustrating to lost
bookmarks and mail accounts with all within.

This is more important than the last DHTML bug. This bug can really damage
Mozillas image.

Regards, Jan
If you want this bug fixed, or even confirmed, I need a set of steps that will
reproduce it every time, with exactly what happens, in detail.

Also: Is it Quickstart or not? Does disabling quickstart make it go away?

-M
Re: exact steps to reproduce the bug.

That would be ideal, but it's not going to happen.
This is the nasty sort of bug, that seems to just have happened one morning when
you switch your computer on for no reason.

I went for months with Mozilla 1.1 fine, then one morning I came in and prefs.js
had been wiped. This seems to be the same for everyone.

We don't know if quickstart is responsible, I don't think it is - I had
quickstart running when the bug his me.

There are more comments about quickstart earlier in this bug.

Please can people posting to this bug say what version of Mozilla they observed
the bug in, and if they had quickstart running.

Russell
Dear Russell, dear Max K-A, dear All,

1/
This is a recent nightly build I updated last week to get out of this:

Mozilla 1.3a

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021204

SO THIS IS NO 1.1 OR WAHTEVER SOLVED PROBLEM!

2/
I do not use Quick Launch at all. 

SO THIS IS DEFENITELY NO QUICK LAUNCH PROBLEM.

3/
SOMEONE ON MOZILLA SHOULD BEGIN TO TAKE THIS VIRAL BEHAVIAOUR SERIOUS!

Thanks, Jan
On my PC (Win2K, Moz 1.2b, Build #2002101612) this bug occurs quite randomly 
whether quicklaunch is activated or not. It is nigh on impossible to duplicate 
the circumstances because you boot up, log on and, wham(!), no prefs.js - all 
mail accounts lost along with all mail. I have now stopped using Mozilla as my 
mail client. This is a most serious bug which has damaged Moz's reputation with 
me and, I'm sure, that if it isn't resolved quickly then there will be others 
that follow ...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Based on comments related to user satisfaction, I am adding nsCatFood, and
nominating for mozilla1.3.

If anybody can tell us what causes this to happen, or what makes this more
likely then please add a comment.

Also, please make sure that your bug is not bug 172245 or bug 132517.

-M
Keywords: mozilla1.3, nsCatFood
I found this report in bug 172245 - looks like it belongs in this bug really ...

------- Additional Comment #3 From Nick Schweitzer 2002-10-09 11:22 -------

I've also had this happen to me (several times), running 1.1 on WinXP. A few of
the times, the system never crashed, I just shut down as normal and when I turn
on the computer the next day, *POOF* all accounts and settings are gone (the
prefs.js AND the prefs.bak have been reset). Until fixed, there is a quick trick
to protect yourself. When you have Mozilla all set up and working normally, make
a copy of the prefs.js file as a backup somewhere else on your computer. If your
settings reset again, simply replace the default prefs.js that comes up with the
one you've saved as a backup. Your settings and accounts should reappear.


Hi All!

(I use the backup prefs method. But I do not think this will fill it for costum
users in production versions as well.)

I do not had the crash again since I do not use the new Junk Mail function
anymore. And I also have not recreated my mail filters till now.

But this is only a speculation...

Thanks for now1

Regards, Jan
I am using build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b)
Gecko/20021217 and with this build it seem to happens less than with previous
builds.
I watched when pref.js was truncated and in my case it wasn't truncated at
shutdown of Mozilla. After booting the pc pref.js is was still there but Mozilla
did ask for a new mail account. When shutting down the new empty pref.js was
saved. My settings are not always completely lost, sometimes 3 of my 4 e-mail
accounts are still there. I'm not using quicklaunch.

Edwin
Blocks: profile-corrupt
Hi All,

After a long delay this bug occurs again on my machine as I thought this could
be solved btw (with Mozilla 1.3b Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.3b) Gecko/20030104. Therefor I had again increased to use the junk mail and
filter functions again (Note I do NOT use Quick start at all.). And so the crash
come back to me. With one exception this time: My bookmarks get not drunked this
time with the mail settings during the clean sweep of the prefs.js and
prefs.bak. I had copies of this files and was so able to restore my mail
settings fine.

Regards, Jan
Note this is a duplicate of http://bugzilla.mozilla.org/show_bug.cgi?id=184902
which I filed recently (or rather, that is a duplicate of this one). I'll add my
voice to say that this happens to me constantly and randomly with Mozilla 1.2.1
on Windows XP. The same version running on Windows 2000 causes me no problems.

Just to echo Russell, "Re: exact steps to reproduce the bug. That would be
ideal, but it's not going to happen. This is the nasty sort of bug, that seems
to just have happened one morning when you switch your computer on for no
reason." That's exactly what happens.

I startup Mozilla first. I startup Mozilla mail first. I surf via DSL. I login
via TMobile. I hibernate my computer, then unhibernate it. There's no way of
knowing when it's going to happen, but when it happens, prefs.js drops to <1K,
my default home page goes away, and I'm asked to re-enter my mail settings.

I'm still using Mozilla mail because the Outlook Express IMAP implementation is
horrid, but I have to keep a good copy of prefs.js on my desktop on that
computer for whenever this bug occurs.
*** Bug 184902 has been marked as a duplicate of this bug. ***
We don't think this is an XP bug.

We have seen it in 98SE - I think that was back in Moz 1.1, but as far as I'm
aware noone thinks they've fixed this bug yet.

Russell
Since 3 weeks I am using a new version of my virusscanner PCCillin 2003 instead
of 2000 and since that time this problem never occurred again. For that upgrade
it occurred almost once a day. (See comment #25)
Edwin, wow, great call! (See comment #30.) It just so happens that the Sony Viao
in question comes with PC-Cillin 2000 installed! I disabled it, and it's been
almost a week with no problems.
*** Bug 191761 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
1)
I just read about our nasty bugs behavior in a posting to Germany's leading and
most serious magazine 'c't' (4/2003 p.184).  A user of Netscape 7 was asking for
help because his multiple mail accounts get lost. 
This seems to mean that this bug has found his way from Mozilla 1.02 in the
production version of Netscape 7!

2)
I also had some lost bookmarks in a Mozilla nightly builds from last week. This
could be interesting here because little trunked bookmarks also occured as side
effect of our bug here. As I had no mail accounts set up in this Mozilla
installation at work I can not determine this. But it could be valuable if we
may assume that the trunked prefs and lost mail accounts could probably be due
faults in other areas of mozilla like the improved bookmarks.
As far as I'm aware, this bug is present in all versions of Mozilla and Netscape.

It is very difficult to track down though, as it can occur very infrequently -
never for most users.

Russell
hi mozilla developers,

i'm the author of the article in geran c't-magazine 4/01 on page 184, which Jan
mentions in comment #34. i was asked by several of our readers about this
problem, even one of our chief editors ran into this bug with netscape 7 :).

i think this is a serious bug and really would like to show our readers a solution.

People who are hit by this issue : Do you use a background virus scanner ?
Flags: blocking1.3?
*** Bug 188125 has been marked as a duplicate of this bug. ***
*** Bug 187846 has been marked as a duplicate of this bug. ***
*** Bug 175362 has been marked as a duplicate of this bug. ***
*** Bug 168184 has been marked as a duplicate of this bug. ***
*** Bug 159033 has been marked as a duplicate of this bug. ***
Alias: prefs_lost
*** Bug 186557 has been marked as a duplicate of this bug. ***
We should look into this for 1.3 final.
Flags: blocking1.3? → blocking1.3+
So, the data that's getting lost here is limited to prefs.js and no other
profile data? In other words, is this a prefs bug or a profile bug?
prefs bug...
Assignee: ccarlen → bnesse
Component: Profile Manager BackEnd → Preferences: Backend
QA Contact: ktrina → sairuh
*** Bug 162609 has been marked as a duplicate of this bug. ***
I'll still own this, since bnesse is no longer here. That question was just to
help me know where to start looking since this seems difficult to repro.
Assignee: bnesse → ccarlen
Target Milestone: --- → mozilla1.3final
Some possible causes of this problem, with descriptions, are:

1. Antivirus software (Trend Micro PC-cillin especially) apparently interferes
with Mozilla, leading to a corrupt or deleted prefs.js. -- comment 30 and bug 175362

2. Using files from old profile in new profile (different *.slt dir name) leads
to corruption. -- bug 95331.

3. Running out of disk space. -- bug 190136.

4. Browser crash. -- bug 164244

5. Mozilla somehow corrupts prefs.js during crash, or system shutdown? -- bug 132517

6. When mail is shut down and then rapidly restarted, all mail is lost. -- bug
182260
All - I've been seeing this bug for several months and reported it.  Just
recently got vectored over to this thread.

In any case, it appears to be tied to my use of Pccillin 2000 - If I disable my
virus scanning, the problem does not reappear.  Although I don't know it as
fact, I believe it was tied to Pccillin getting its update from their server -
at least it seemed to be tied to that.

Kevin N. Carpenter
andrew, thanks a lot for compiling that list of related bugs!

jan / russell, do any of the scenarios described in comment 48 fit with your
situation?
only this one looks possibly relevant:

5. Mozilla somehow corrupts prefs.js during crash, or system shutdown? -- bug 132517

although I'm sure I've seen it happen without a noticeable crash of Mozilla

I'm pretty sure we've seen this bug with no antivirus running.

I've definitely never had PCcilin running.

I normally use Norton Antivirus, and I've seen the bug happen with that running.

Russell

I'm running Linux (Mandrake 8.1).
I don't think this is antivirus related. I've had this mail box thing 4 or 5
times  already, all of them after a crash, wich I can't identify.
It doesn't seem to be a reproduceable bug/crash, and it has a random frequency
of occurrence.

Artur Correia
*** Bug 188992 has been marked as a duplicate of this bug. ***
*** Bug 192906 has been marked as a duplicate of this bug. ***
I'm a Mozilla user on XP and have not had this bug occur since I discontinued
use of my VirusScan (AVG) program.
Other maybe related dataloss bugs are:

Bug 171353: Newly downloaded mails lost after system crash
Bug 186169: Unread messages lost on mozilla crash
Bug 116443: Deleted inbox after receiving virus infected mail

Probably they are different dataloss bugs (with Mozilla crash, deleted
inbox...), but perhaps with some relation.
I lost my preferences recently with the release version of 1.2.1 under windows
XP.  My computer was unstable, due to something unrelated to mozilla, and I had
to forcably restart.  I thought Mozilla was properly closed first, but perhaps
it hadn't finished writing something to disk.  After restarting, I still had
bookmarks, but I had lost preferences.  I had to recreate mail accounts, but the
data from old accounts was still in the profile.  I have Norton Antivirus
corporate edition, but real-time scanning is disabled.  I do not use quickstart.
For those who have witnessed this:
After the preferences are reset, what exactly is left in the file prefs.js?

It would be helpful to know if the prefs table is for some reason empty in
memory and gets written out, or the prefs table is fully populated but the write
gets truncated.

Alec - were you involved in the prefs.bak work? Any ideas here?
 is there any chance a new profile got created? did you lose your bookmarks too?
(which would be a good indication of whether or not you also lost your profile)

as for prefs.js/prefs.bak - I haven't seen issues with that in a long time...

but I do remember there was some issue with quicklaunch and profiles - where
prefs.js would get written out before the new prefs were loaded, etc.. I don't
know exactly what was causing it though - I thought it was fixed.
Alec: all bugs are only from a lost prefs.js. (not the whole profile or the
registry.dat/appreg.dat file). Mozilla still finds the old bookmarks but all
prefs are lost. (seetings, configured Mail Accounts...)
> Alec: all bugs are only from a lost prefs.js. (not the whole profile or the
> registry.dat/appreg.dat file). Mozilla still finds the old bookmarks but all
> prefs are lost. (seetings, configured Mail Accounts...)

except for bug 191761, which you duped here (also happens to be the only linux
instance of this bug)...  if this bug does not affect bookmarks, that bug should
be reopened.
*** Bug 193542 has been marked as a duplicate of this bug. ***
Depends on: startup
datapoint for ccarlen:

this reminds me a of a mac commercial only-bug that recently got marked worksforme.

mac doesn't do quicklaunch, but it might be related

(nbaca / gbush, do you remember the bug #?)
The _bugscape_ bug seth is talking about is 21796.
Another theory is that when a profile is mounted on a network drive (or NFS
mount), profile locking might not be working, so prefs.js may get overwritten if
the user starts a second instance of Mozilla with the same profile. Bug 158326.
> It would be helpful to know if the prefs table is for some reason empty in
memory and gets written out, or the prefs table is fully populated but the write
gets truncated.

In order to help determine this, we could write a line:
// EOF
into prefs.js after the last entry was written. Then, it would be possible to
know at what stage the data loss occurred.
Re: comment 58, comment 66

Perhaps, in addition to other improvements for prefs.js and prefs.bak files,
part of a possible solution would be also something similar to the fix for bug
86501 (fixed in nsBookmarksService::WriteBookmarks):

5078   // If we wrote to the file successfully (i.e. if the disk wasn't full) 
5079   // then trash the old bookmarks file and rename the temp file so it takes
5080   // its place. 
5081   if (succeeded) {
...
5093   else
5094     // Failed. Delete the temporary. 

http://lxr.mozilla.org/mozilla/source/xpfe/components/bookmarks/src/nsBookmarksService.cpp#5078
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp#5078

From CVS Blame:

"Fix for bug 86501 - bookmarks.html file is truncated to 0-length when shutting
down with a full profile disk. Write bookmarks to a temporary file, and rename
that to 'bookmarks.html' only if the write operation succeeded."

It seems that nsPrefService::WritePrefFile does it in a different way. If I'm
not wrong, it makes a backup (or tries to), then overwrites the preferences file
and then, if something went wrong, tries to restore the lost file from backup:

http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/nsPrefService.cpp#349

Differently, the fix for the bookmarks bug does not delete the original file
until there is a new correct file ready to substitute it (by renaming). It's
simple, but maybe safer (for low memory situations, etc.).

A mix of the two solutions would delete only the old backup prefs.bak, then
would create the new file prefs.tmp without overwriting prefs.js, and then -if
everything is OK- would do some renaming: prefs.js -> prefs.bak, and prefs.tmp
-> prefs.js. Just a possible idea, naturally.

Yes, writing to a temporary file and then replacing the actual file when the
save has completed is the way it should be done. See bug 192425. That's one
avoidable case of prefs loss to be pursued, but I don't think that's the entire
problem here (wish it was).
*** Bug 190386 has been marked as a duplicate of this bug. ***
*** Bug 174321 has been marked as a duplicate of this bug. ***
*** Bug 162290 has been marked as a duplicate of this bug. ***
*** Bug 183145 has been marked as a duplicate of this bug. ***
I noticed that Mozilla (still using 1.2.1) sometimes refuses to comply with
shutdown (Atlon/Win2kSP3) even if the profile disk is not full. Windows
complains that it doesn't respond to order to get out. This seems to be limited
to Quicklaunch mode and happens one in three times.

Possibly this is related?
Depends on: 123184
Re: comment 74

> (...) shutdown (...) Quicklaunch (...)

Well, the prefs.js file is lost sometimes and under various circumstances, like
the one you've described. So, you suggest that something wrong can happen in
that case (shutdown). From what people say, it seems that it's so, but I think
the problem is that the function nsPrefService::SavePrefFile (wich calls
nsPrefService::WritePrefFile) is called from about 28 different places in 17
files of the Mozilla source code (see
http://lxr.mozilla.org/seamonkey/ident?i=SavePrefFile ).

That is to say, there are probably several situations where WritePrefFile can
lose prefs.js. I think WritePrefFile is the only function that currently uses
the class nsSafeSaveFile, which does not seem to be completely safe under every
circumstance. IMHO the succesful bookmarks fix -renaming temp file instead of
overwriting original file- would be one of the safest and most effective ways
(bug 86501, above quoted in comment 67 and 68), and not only for low memory
situations. Sometimes a simple solution is safer, without the possible places to
lose data in the current writing procedure.

So, in brief, to prevent data loss, I think one of the things to do would be to
improve the safety of WritePrefFile, like other people suggested (bug 192425, a
related case also quoted in another comment). And of course in addition to make
other safety improvements for the most frequent cases of prefs.js loss,
naturally. I think we probably agree on this. :-)

There are a lot of similar bugs regarding corrupt localstore.rdf files. Could we
implement the same practice of writing a tmp file first, then renaming it once
it is known to be good for localstore.rdf? (If this is inane, apologies in advance.)
A few comments that might help:
I am using Mozilla since a very long time (back to 0.9.x) on different platforms
(NT4, 2000 at work; XP, Linux at home). Until now this bug never happened to me.
I would like to mention the following guesses:
- I am using Quicklaunch at work, not at home. This seems not to be the problem.
- When installing a new version I always kept the bookmars.html file only. ALL
others I removed (including deep-cleaning the registry on Win-machines).
- I am NOT using Mozilla Mail at all. Maybe that IS indeed a factor.
A question arises in my mind:
Are the people that are affected by the bug do all use Mozilla Mail?

Or it might have to do something with the virus scanner.
Pro:
- Virus scanners check .js-Files.
- Virus scanners allow automatically deletion of suspicious files
Contra:
- I am using NAV 2002/2003, no proplems
- Standard case is that the virus scanner asks before any desinfection

With regards,

Martin.

This file demonstrates the basic cause of this bug. Specifically, prefs.js is
written with around ~41 seperate write operations. If the machine crashes
half-way during the write process, prefs.js is truncated. The solution is to
use a journaled write mechanism, or to simply buffer the file in memory and
write it in one chunk.
My theory is that the problem is caused by the way prefs.js is written to disk.
On my machine, simply closing the last browser window will result in 164 disk
operations on the "prefs.js" file, including 41 seperate write operations. If
the computer or Mozilla crashes during those write operations, the prefs.js file
is corrupted.

This kind of sloth is simply unacceptable! While many boast that open-source
software is of a better quality than commercial software, one would think that
such a basic error would not have made it into Mozilla, especially considering
that this bug has been known since version 1.0!

o Why isn't the file write buffered? Looking at the log of activity reported by
FileMon, it looks like the file is being written one line at a time, with
newlines (2 bytes under NT) written as a seperate disk access!
o More importantly, why isn't the file write journaled? Most Windows
applications (eg: Word) that write files to disk will journal the write. That
is, Mozilla should write prefs.js to a temp file (eg: prefs.js.tmp), then
replace the original with the new file using a pair of file-delete and
file-rename operations. This way, if the write fails, the original will not be
replaced, preventing corruption.
o Why would a corrupt prefs.js file blow away all settings, including mail? My
mail files are STILL THERE! Why can't I open them? With, say, Outlook, I can
open a PST file any time, on any computer, with or without my 'preferences'.
Notice that Mozilla does not have a menu option for importing mail from Mozilla.
How can it not understand it's own file format?

Bugs like this, combined with the strange habit of the Mozilla Dev team of
copying not just the features but the design flaws of Netscape is why Mozilla
will never regain the market share IE stole from Netscape.

>Why would a corrupt prefs.js file blow away all settings, including mail?
A corrupt prefs.js doesn't blow away your settings.
You wil get a warning that the file is damaged.
see bug 193638

Mail importing doesn't belong in this bug ! 
We have another bug for importing mbox files. 

And Mozilla will never get the market share of IE since Mozilla is not for Users
(unlike IE).


Re: comment 79
> My mail files are STILL THERE! Why can't I open them? (...)
> Notice that Mozilla does not have a menu option for importing
> mail from Mozilla. How can it not understand it's own file format?

Re: comment 80
> We have another bug for importing mbox files.

Yes, there are some, and the main one seems to be the following:
Bug 63389 - Need options for importing 4.x and Mozilla mails (mbox)
See also bug 171828, bug 172013...

Peter, thanks for your suggestion of possible solutions for this prefs.js bug,
and sorry for your problem. Perhaps it should be emphasized, in the "Download
Mozilla" section, that we as testers should keep backups of all the important
files, like prefs.js.

Anyway, there is a solution to recover the mail messages "by hand", for those
with the same problem (remember to remove the mail summary files *.msf, and keep
the files with no extension, like Inbox, etc., where the messages are stored):

http://www.mozilla.org/start/1.0/faq/mail-news.html#3.8
http://www.mozillazine.org/forums/viewtopic.php?t=1901
http://www.mozillazine.org/forums/viewtopic.php?t=4837
http://www.mozillazine.org/forums/viewtopic.php?t=2450

Also, Netscape is based on Mozilla, so I think they use the same mailbox format
(standard mbox text files).

The fact that all my mozilla dependent user settings get lost happened after
system reboot(crash) following a link click operation.
Settings:

OS: Win XP Home Ed. ver. 2002 (SP1) active.
2.OS installed: WIN 2000 Prof. using same Mozilla Version on both platforms.
Moz Ver: Mozilla 1.3a
         Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) 
         Gecko/20021212
         Quickstart not enabled

At that time 3 (Ctrl+N) Moz windows were open. Urls were:
 -  yahoo.com(bgr)
 - www.echo-online.de(bgr) 
 and a search site from www.echo-online.de (fgr).
Clicking on a detailed search link caused mozilla to crash.
After immediate (automatic) reboot, all settings have been lost and could be
found in the trash can and therefore restored.
A user reported that in a German computer magazine, too. 
I just read all the comments in this bug and noticed a few things
that seem worth emphasizing.

1. In comment #25, Edwin Flinterman claims he ran Mozilla; he was asked for
email account info (as if his prefs.js had been wiped); he noted that prefs.js
was NOT truncated at this point; he shutdown Mozilla; he took another look and
noted that prefs.js and prefs.bak WERE now truncated.

2. 6 separate posters (in comments 12, 20, 21, 25, 26, 57, 82) claim they hit
the bug while /not/ using QuickStart. Presumably the problem is not in
QuickStart (though QS might exacerbate it).

3. 7 posters note that the problem occured immediately after rebooting their PC,
in several cases with nothing untoward seeming to have occured beforehand. 

4. 3 posters (30, 31, 49) claim that the bug happens fairly frequently when
running the anti-virus PC-Cillin 2000 and not at all when they disable it. One
of these notes that the updated PC-Cillin 2003 seems to be OK. Another av called
AVG might be another trigger based on comment 55.

Hth.
If fixing this for prefs.js and the other profile files is going to involve
rewriting a lot of code, maybe it would be too late for 1.3 final. This should
be fixed the right way. If that means pushing it to 1.4, then that would be just
fine.
Keywords: nsbeta1
> and the other profile files is going to involve rewriting a lot of code

This bug is about *only* prefs.js, not other profile files. As it stands, the
problem with prefs.js is very hard to pin down and, if we start throwing all
other profile data loss problems in here, forget it.

Unfortunately, this could get fixed for 1.3 only if we had a proven cause, a
proven fix, and the fix was low risk.
The underlying problem is the many writes to a single profile file for a single
save (not saving file in memory and writing it in a single chunk) , and not
creating a temp file first and then renaming it. This problem applies to
prefs.js, localstore.rdf, bookmarks.html, mail, and, AFAICT, all profile files
that Mozilla writes.
ok, can you open a new bug for the fact that we make about 20 times the writes
that we need to for prefs.js. You may be right about the other files as well,
but the writing of these files has different codepaths...really we should be
using some sort of buffered output stream to write this file.

Re: comment 58
>It would be helpful to know if the prefs table is for some reason
>empty in memory and gets written out, or the prefs table is fully
>populated but the write gets truncated.


From the variety of reports, it seems likely that the two causes are happening:
loss in memory and loss writing. I don't know if they are 20%+80% or 80%+20% of
cases.

Maybe this comes from low RAM memory situations (this happens sometimes in the
case of Windows after using it for a while), conflicts with other programs...

Anyhow, it's possible that the already mentioned strict checking (at least of
expected size) of a written temporary file before renaming it as prefs.js could
fix a good part of the two cases, until more complete fixes can be applied.

In addition to this, in order to avoid loss of important data like mail
settings, probably you will agree that, on the one hand the preferences written
directly by the user, and on the other hand other different data saved
automatically and constantly, they should be written in two different files, not
one.

The first file, saved only during installationa and when the user makes directly
any change, with confirmation "Save preferences?" or similar. Perhaps the users
do this once a month. Why to save it constantly?

The second file, saved maybe every few minutes or seconds, with settings like
(copying this from my prefs.js):

user_pref("browser.url_history.URL_15", "http://www.mozilla.org/");

Re: comment 79
>(...) prefs.js is written to disk. On my machine, simply closing the last
browser window (...)

I've just done some testing, and it seems that -at least in Windows- prefs.js is
saved when closing Mozilla. So, in my case, prefs.js is saved just several times
a day and not every few minutes as I was afraid of. :-)

Given that in most cases people is losing prefs.js precisely when closing
Mozilla, I really think it is necessary to separate the data in two files as
said before: user's entered and confirmed data (mail settings, etc., rarely
changed), and automatic data (browser history...).

I've just found something interesting regarding this prefs.js bug, but maybe I'm
the last one to know it. :-)

I was now searching for some info at:

Files in your Mozilla profile directory
http://gemal.dk/mozilla/files.html

And they say:

"user.js - User setting which will be written into prefs.js after Mozilla is
started"

I don't have any users.js file. So, more searching:


"user.js is a user-created file that lets you keep your custom preferences in a
file that Mozilla will not alter (unlike prefs.js)."

Mozilla 1.0 FAQ
1.5. Hidden preference
http://www.mozilla.org/start/1.0/faq/general.html#1.5


"Neither Netscape or Mozilla will overwrite the user.js file. Options added to
the user.js file will overwrite those in the prefs.js file. Another perk of the
user.js file is that you can edit the file with Netscape or Mozilla open, unlike
the prefs.js. The scripts entered in this file will override the prefs.js scripts.
You must also be mindful that any edits to the user.js file are recorded in the
prefs.js file. Thus, if an entry is deleted in the user.js, you will also need
to delete that entry in the prefs.js file.
(...)
The default backup method for Netscape 7/Mozilla backs up the prefs.js file when
you close mozilla, which is when it writes to the prefs.js file. It does work,
but manual is better for peace of mind. Of course, this is the reason to keep
most of the options in the user.js file, and keep them properly commented."

The user.js file
http://home.att.net/~cherokee67/ns7theuserjs.html


More info at:

Customizing Mozilla: Other Useful Preferences
http://mozilla.org/unix/customizing.html#prefs

NewZilla: Hidden Preferences
http://www.gerbilbox.com/newzilla/mozilla/usingmoz10.php#prefs


As I said, I think that another file with rarely changed but important settings
should be available for all users and testers, not only for advanced users who
edit the user.js file by hand.

Although user.js is an interesting option as well. :-)

please don't bring user.js into this - its support is minimal, if it even still
works. There are about 9 people in the world who use it and those of us who
maintain libpref hate it because it really makes our job much more difficult.
I upgraded from 1.2.1 to 1.3b and I experienced this bug, too. I'm using 
quicklaunch. All my settings (bookmarks, start-page, email accounts) are gone.
alecf: the release notes suggest user.js :)
noooooo!
I think I just experienced this bug for the first time. I was browsing along
happily when the accounts wizard popped up asking for my name and email address.
 I've been following this bug for a while, so I quickly backed up my prefs, then
canceled the dialog. Closed down Moz, shut down computer and restarted - but the
prefs weren't wiped. 

Well, except that I got the popup message 'you are leaving an encrypted page,
blah blah' window. Apparently the pref that I don't want that window to pop up
was lost. But I did a diff between my old and new prefs and nothing really
changed. Could cancelling the wizard dialog be a workaround for this bug, or did
I just get really lucky?

moz1.3b, WinME, no quickstart, running Norton AntiVirus
*** Bug 194884 has been marked as a duplicate of this bug. ***
Just a thought:
i experienced this a long time ago, exactly the same as described here. Perhaps
while writing the prefs.js file to the disk, it is somehow silently blocked by
the users antivirus software, since a lot of that software today contains
scriptblocking features and seems to be very sensitive to anything involving
javascript, wherever it is on the computer, in whatever format (well, at least
norton is).
There is some interesting data this on bug 193638, comment 35.

It shows, IMO, that the prefs hash table is being fully written out, but it's
being written at some wrong moment at which it's nearly empty. In the incomplete
copy, notice user_pref("mail.smtpservers", ""); The line is fully written, and
other prefs are written afterwards. Also, in the complete version, there are
other prefs in alphabetical order between corresponding prefs in the incomplete
version.

There is no incomplete I/O, virus software interaction, etc. that could do this.
The prefs file is somehow being written at the wrong time, when the in-memory
data has been mostly reset. 
Conrad, this is pretty catastrophic dataloss and it would be a shame to ship it
in 1.3. Are you going to be able to debug and fix this in the next few days? Can
we get more help for it?
> Can we get more help for it?

What would be helpful would be more info like somebody provided on bug 193638,
comment 35. Since nobody can repro this, I just need detailed info on what
happens and then maybe can tell what's causing it. 

Anybody that's familiar with the prefs code would be helpful.

I've been following the bug and unfortunately, I don't feel like I have any
greater clue about this - I guess it might just be a matter of wandering through
the prefs code and see if we can spot something

the other possibility is that if we really are talking about a half-created
prefs table, that we need to just put a lock around all accesses to the prefs
hashtable. maybe one thread is writing out the file while another thread is
mucking with the table?
I'm glad others have finally noticed this bug. As no one seems to be able to
reproduce it, I went back to my Sony Vaio to see if I could.

I haven't seen this bug since before 22 January 2003 when I disabled PC-cillin
2000 (see comment #31). I made a backup of pref.js, then I started up PC-cillin
Real-time Monitor, and turned on Real-time Scan. I started Mozilla, then Mozilla
Mail. Then Mozilla Mail, then Mozilla. No problems.

Then I started Mozilla Mail with my taskbar shortcut, then started another
instance of Mozilla Mail with the shortcut Windows XP makes available when you
tell the taskbar to use Mozilla Mail as the default mail. I shut down both
copies of Mozilla Mail and Mozilla, and the next time I started Mozilla, I was
looking at the default mozilla.org home page. (Note that later I reproduced this
by starting two Mozilla Mail instances by clicking on the same taskbar shortcut.)

Now, here's the interesting thing: after I had shut down all instances of
Mozilla and then started a new Mozilla instance from scratch, I was shown the
default home page as if the settings were gone---but the prefs.js in the
directory was exactly the same as the one before the settings were gone! It's
after I shut down *this* instance of Mozilla that my prefs.js dropped to an
almost empty file. The contents of prefs.js were then:

# Mozilla User Preferences
// This is a generated file!

user_pref("browser.bookmarks.added_static_root", true);
user_pref("browser.startup.homepage_override.mstone", "rv:1.2.1");
user_pref("intl.charsetmenu.browser.cache", "ISO-8859-1");
user_pref("network.cookie.cookieBehavior", 0);
user_pref("prefs.converted-to-utf8", true);
user_pref("timebomb.first_launch_time", "1046383599730000");

This leads me to several conclusions:

1. Anti-virus software somehow interacts to make this problem appear.
Absolutely. (Otherwise, it would be pure luck that the problem went away on 22
January 2003, the same day I disabled PC-cillin 2000, and then did not reappear
until minutes after I restarted PC-cillin 2000 over a month later.)

2. This doesn't seem to have anything to do with a truncated/corrupted prefs.js
write. The preferences were gone *before* the prefs.js file was modified, not after.

I have *not* looked at *any* Mozilla code, but here's a thought: maybe
anti-virus software prevents Mozilla from *reading* prefs.js on startup, and
when this happens Mozilla thinks prefs.js is corrupted, switches to defaults,
and generates another prefs.js on shutdown. Similarly, Mozilla might attempt to
open the file for writing on startup, and the anti-virus software could prevent
opening for write access even without Mozilla trying to write anything, and
Mozilla might see the failure to open with write access as a file problem, and
switch to defaults.

Hope this helps.

Garret
Same thing happens to me on two different W2K clients on a network of 8 pc,
every few days. We keep copy of prefs.js to restore but I do have do it manually
for the users so it's pretty much of a problem... 

I would not go for 1.3 with this bug open since Windows users do not have many
other valid alternatives switching from Outlook and the Mozilla browser+mail
should be pretty much used.

On other clients on the same network it's not happening... all of them have the
same configuration and all of them use an antivirus (AVG) running in the back.
All of them also have the theme Orbit 3+1 installed.
I am also facing this problem running PCCillin, on windows 2000 on a Sony Viao
PCG_GRX580.
Re: comment 102
>maybe anti-virus software prevents Mozilla from *reading* prefs.js
>on startup, and when this happens Mozilla thinks prefs.js is corrupted,
>switches to defaults, and generates another prefs.js on shutdown.


It's possible that this may explain a good part of the cases of loss of
preferences. To verify if that is the default prefs.js, any of us can do a
simple test -even if this bug hasn't happened to us- renaming (to restore later)
prefs.js to prefs-old.js or something before opening Mozilla. If I do it,
Mozilla creates a two-lines prefs.js like this:


# Mozilla User Preferences
// This is a generated file!


And, closing Mozilla, this is overwritten by the following prefs.js (I use
Mozilla 1.2.1 for Windows, without Quick Launch):


# Mozilla User Preferences
// This is a generated file!

user_pref("browser.bookmarks.added_static_root", true);
user_pref("browser.startup.homepage_override.mstone", "rv:1.2.1");
user_pref("intl.charsetmenu.browser.cache", "ISO-8859-1");
user_pref("network.cookie.cookieBehavior", 0);
user_pref("prefs.converted-to-utf8", true);
user_pref("timebomb.first_launch_time", "1046393798440000");


This way, we can see a default prefs.js.

The prefs.js of comment 102 is:


# Mozilla User Preferences
// This is a generated file!

user_pref("browser.bookmarks.added_static_root", true);
user_pref("browser.startup.homepage_override.mstone", "rv:1.2.1");
user_pref("intl.charsetmenu.browser.cache", "ISO-8859-1");
user_pref("network.cookie.cookieBehavior", 0);
user_pref("prefs.converted-to-utf8", true);
user_pref("timebomb.first_launch_time", "1046383599730000");


So, the same default prefs.js, excepting the time data of the last line,
naturally. So, it's possibly true that in the case of the comment 102 the
antivirus program prevented Mozilla from reading the original prefs.js.

But other cases are different. The one mentioned by Conrad (comment 98) had the
following corrupted prefs.js:


# Mozilla User Preferences
// This is a generated file!

user_pref("mail.smtpservers", "");
user_pref("mail.ui.folderpane.version", 2);
user_pref("mailnews.ui.threadpane.version", 2);
user_pref("prefs.converted-to-utf8", true);


Perhaps in this case the empty preferences table was starting to get a few new
values in memory, before closing Mozilla and saving the prefs.js file. Well, I
don't know. (?)

If other people may confirm if they got a small prefs.js file like those, or
there are also cases of a completely deleted or zero-length file, probably that
would be useful to know about the variety of possible cases and causes.

About my suggestion (comment 88) to avoid saving prefs.js so often by moving
automatic stuff like browser history to a different file, I only would suggest
that if it does not imply too much difficult to maintain code like in the other
-different- case of the user.js file. Just a point of view, naturally. :-)

Re: comment 93, 94
>>the release notes suggest user.js :)
>noooooo!

All right, let's forget about user.js. :-)

Another detail. Starting Mozilla with only the mail client instead of the
browser (without prefs.js file, see comment 105), and refusing to create any
mail account, the default prefs.js becomes the following:


# Mozilla User Preferences
// This is a generated file!

user_pref("mail.smtpservers", "");
user_pref("mail.ui.folderpane.version", 2);
user_pref("mailnews.ui.threadpane.version", 2);
user_pref("prefs.converted-to-utf8", true);


That is to say, exactly the same of the comment 98. Therefore, like in the case
of the comment 102, the corrupted prefs.js is a default prefs.js.

If we start Mozilla with the browser and later we visit a moment the mail
client, Mozilla creates the following default prefs.js:


# Mozilla User Preferences
// This is a generated file!

user_pref("browser.bookmarks.added_static_root", true);
user_pref("browser.startup.homepage_override.mstone", "rv:1.2.1");
user_pref("intl.charsetmenu.browser.cache", "ISO-8859-1");
user_pref("mail.smtpservers", "");
user_pref("mail.ui.folderpane.version", 2);
user_pref("mailnews.ui.threadpane.version", 2);
user_pref("network.cookie.cookieBehavior", 0);
user_pref("prefs.converted-to-utf8", true);
user_pref("timebomb.first_launch_time", "1046402278110000");


That's the sum of the browser and mail defaults. So we can start to understand
what may happen, at least in cases like those of comment 98 and comment 102. Are
there other different cases, perhaps?

Today it happened to me, too:

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.3b) Gecko/20030210

- Started WinXP on 6:14, login
- started Mozilla 1.3b
- Got dialog "create a new account". 
- Canceled Dialog, Shutdown Mozilla
- prefs.js AND prefs.bak created 6:17 with 529 Byte, same content 
  as in comment #106, except
  user_pref("timebomb.first_launch_time", "1046409334361043");
- bookmarks.html was also reset to default
  (350 Byte, just contains "Imported IE Favorites")

Achim
Re: comment 107
>prefs.js AND prefs.bak created 6:17 with 529 Byte


That seems to be the browser + mail default.

Default prefs.js sizes (on my Windows PC):

60 bytes - Temporary, 2 lines
400 bytes - Only browser, 6 lines
235 bytes - Only mail, 4 lines
530 bytes - Browser and mail, 9 lines (line on utf8 is shared)

Possibly Garret is right in comment 102, and Mozilla sometimes is unable to read
the existing prefs.js file (because of antivirus or any other reason), therefore
overwriting it with defaults on shutdown. At least in some recent cases of loss
of preferences.

Failure to read the prefs, and then writing out defaults, does seem to be
possible. See
http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/nsPrefService.cpp#456

nsFileInputStream::Read doesn't return an error if the actual count read is less
than the requested count. In this case, I think a partial read should be
considered an error and set gErrorOpeningUserPrefs.
Attached patch more checking on reading the prefs file (obsolete) (deleted) — — Splinter Review 

    
    

    
  
A quick look at the nsPrefService class shows me that there is no thread
protection on reading and writing the preferences file.  Add some mutexes here!
I have not looked at the rest of the code but I assume that this is a
multithreaded application.


    
    

    
  
Comment on attachment 115881 [details] [diff] [review]
more checking on reading the prefs file

Alec - who else knows this code?

        Attachment #115881 -
        Flags: superreview?(alecf)

    
    

    
  
Just finished reading this thread and here are my findings from a recent crash:

1) Mail settings lost, but files were kept, I had changed the Mail ISP from a
mrtech.com to localhost for a local proxy and the crash created a localhost
folder in the Mail folder, but the mrtech.com folder was still there.  Copying
over files seemed to work.  But I had to redo all the other settings.

2) I had "Tweaked" my Windows XP shutdown time which leads me to believe that
this definitely is a timing issue between, processor/harddrive speed and giving
Moz enough time to write out the 41 instructions.  Making this a journalized
write would probably alleviate this.  I can forward registry entries to hack to
try to reproduce this.

3) The anti-virus thing might be the inefficiencies in the older apps to quickly
test files for virus, thus holding up the write process.

Proposed:

- Besides creating a one-write journalized method, one INCREDIBLY awesome option
would be a tool or advanced option to backup current configuration.  This would
definitely help when prefs or other files get bombed.  Something like Recall I
guess: http://recall.mozdev.org/

- Another idea would be to set a toggle that registers the fact that mail has
been configured, for example after the first successful shutdown and save the
mail settings, etc in a different back up file.  If this toggle was set or
backup files existed and a new mail profile needed to be created, because of a
crash of the prefs.js file, that it should prompt to use the back up prefs or
the other saved settings.

- Seperating the general prefs.js options and the mail settings would also be an
incredibly useful option, this way if a crash occurs there's hopefully a little
less to have to recover from.

All are really tough, but would really help against user/my frustrations.

Mel

    
    

    
  
Comment on attachment 115881 [details] [diff] [review]
more checking on reading the prefs file

hey, looks good to me.
sr=alecf

        Attachment #115881 -
        Flags: superreview?(alecf) → superreview+

    
    

    
  
Comment on attachment 115881 [details] [diff] [review]
more checking on reading the prefs file

oh, and I guess dveditz is the next best person to do the review... but I still
contend that we might want to start wrapping access to gHashtable with a
lock/monitor.

        Attachment #115881 -
        Flags: review?(dveditz)

        Attachment #115881 -
        Flags: review?(dougt)

    
    

    
  
Comment on attachment 115881 [details] [diff] [review]
more checking on reading the prefs file

i don't think that you need that else block.  fix that up and r=dougt.

        Attachment #115881 -
        Flags: review?(dougt) → review+

    
    

    
  
> i don't think that you need that else block.

spoke to dougt on AIM. all is okay

    
    

    
  
Comment on attachment 115881 [details] [diff] [review]
more checking on reading the prefs file

I'm not sure this patch is sufficient -- how sure are you this is the only
problem here? (Doug's wrong about the else branch -- it's the primary point of
this patch.)

If we can't get the filesize we bail without setting the "no-write" flag. Since
it looks like the only way GetFileSize() returns a failure is if the file
doesn't exist that's fine -- we do want to be able to re-create prefs.js if
it's gone.

But we also don't set the flag if the NS_NewLocalInputStream() or malloc fails.
Of the two in this case I'm worried about the input stream -- without having
reproduced the problem it seems just as likely to me if not more that PCCillin
is not letting us open the file than that it's causing a partial read as this
patch assumes.

        Attachment #115881 -
        Flags: review?(dveditz) → review-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch v2 (deleted)
        — 
          — Splinter Review
      

    


  
Dan, without being able to repro the bug, I can't say this is the entire
problem. But, it could cause us to write out a default prefs.js so it should be
fixed. This  patch should be safer yet. Once we know the file exists, it
assumes failure until it finally succeeds.

        Attachment #115881 -
        Attachment is obsolete: true

        Attachment #116163 -
        Flags: review?(dveditz)

    
    

    
  
Comment on attachment 116163 [details] [diff] [review]
patch v2

Thanks! Since we don't know exactly where we're failing this looks safer.
r=dveditz

        Attachment #116163 -
        Flags: review?(dveditz) → review+

    
    

    
  
Comment on attachment 116163 [details] [diff] [review]
patch v2

ok, that works too.. sr=alecf

        Attachment #116163 -
        Flags: superreview+

    
    

    
  
Checked into trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
Comment on attachment 116163 [details] [diff] [review]
patch v2

It's in the trunk - now seeking approval for 1.3.

        Attachment #116163 -
        Flags: approval1.3?

    
    

    
  
Comment on attachment 116163 [details] [diff] [review]
patch v2

a=asa (on behalf of drivers ) for checkin to 1.3 branch.

        Attachment #116163 -
        Flags: approval1.3? → approval1.3+

    
    

    
  
if someone could verify that this is fixed with a build from tomorrow, that'd be
great.
Keywords: verifyme

    
    

    
  
   NS_ASSERTION((amtRead == fileSize), "failed to read the entire prefs file!!");
+  if (amtRead != fileSize)
+    return NS_ERROR_FAILURE;
  #ifdef XP_OS2 /* OS/2 workaround - our system editor adds an EOF character */
      if (readBuf[amtRead - 1] == 0x1A) {
         amtRead--;
      }
  #endif

Um, shouldn't the OS/2 workaround be placed before the check? Or is the EOF
character included in the given file size?

    
    

    
  
> Or is the EOF character included in the given file size?

I would think so. CC'ing mkaply to confirm.


    
    

    
  
EOF character is included in the filesize. This fix should be fine for OS/2.

I'll check our failing case just to be sure.

    
    

    
  
Checked into 1.3 branch.
Whiteboard: fixed1.3

    
    

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

    
    

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

    
    

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

    
    

    
  
I'm using Mozilla 1.3 20030312. The bug is still there, and it's just as easy to
reproduce---I can get prefs.js wiped in 30-60 seconds just by randomly opening
random browser and mail instances with PC-cillin running.

If someone wants a machine on which they can easily reproduce this bug, you I'll
gladly trade my laptop for one of those new Dell Pentium-M machines... ;)

    
    

    
  
the new bug for this is bug 197677.
Conrad: could i generate a useful log with a debug build and installed pc cillin ?
(If i find pc-cillin somewhere)


    
    

    
  
Matti: that would be great. If PC-cillin creates a log, maybe it will tell us if
it did anything to prefs.js and why?

    
    

    
  
Re: comment 134
>(If i find pc-cillin somewhere)

PC-cillin
http://www.trendmicro.com/en/products/desktop/pc-cillin/evaluate/overview.htm

There is a 30-day trial version of PC-cillin 2003, but several comments talk
about this bug with PC-cillin 2000. See for example comment 30:

>Since 3 weeks I am using a new version of my virusscanner PCCillin 2003
>instead of 2000 and since that time this problem never occurred again.
>For that upgrade it occurred almost once a day.

Some general info and user comments (positive and negative) on PC-cillin
versions, at CNET.com:

PC-cillin 2000, 2002, 2003
http://www.cnet.com/software/0-806174-1204-4913863.html?tag=pdtl-list
http://www.cnet.com/software/0-806174-1204-9682410.html?tag=pdtl-list
http://www.cnet.com/software/0-806174-1204-20722940.html?tag=pdtl-list


Re: comment 135
>If PC-cillin creates a log, maybe it will tell us if it did anything to
>prefs.js and why?

There is a support article that I don't know if it could be related to some
cases of this bug:

"Problem:
When using certain email client programs, PC-cillin 2000 changes the POP or Post
Office Protocol server settings to 'localhost' and the username field or box to
'username/pop server name'.
This issue has been reported for the following email clients:
 * Microsoft Outlook 2000
 * Microsoft Outlook Express
 * Netscape Messenger"

http://kb.trendmicro.com/solutions/solutionDetail.asp?solutionId=10700

Other similar PC-cillin support articles:

http://kb.trendmicro.com/solutions/solutionDetail.asp?solutionID=13831
http://kb.trendmicro.com/solutions/solutionDetail.asp?solutionID=11214

    
    

    
  
This happened to me when I changed from a normal POP connection to using
Spampal, the prefs where lost and the mail settings were overwritten and a new
subdirectory was created under the mail directory called 'localhost' instead of
my POP address, but I think this might be unrelated and I'm definitely not will
in to recreate this.  I was able to salvage everything by moving everything
under localhost and making sure that all paths in the prefs where ok.

    
    

    
  
Seems to me that Pc-cillin was the cause of my problems ... Removed it about 3
weeks ago and replaced it with AVG. Running Mozilla mail as a "backup" email
program (just in case prefs.js did get deleted again) and it is running
perfectly well. Hope these aren't famous last words ... :-)


    
    

    
  
> Seems to me that Pc-cillin was the cause of my problems

Can somebody who owns Pc-cillin ask their tech support about this problem? 

    
    

    
  
I've asked them in the past.  Was told it was a Mozilla problem.

    
    

    
  
A possible fix for this bug would be to change the name of the preferences file
to "prefs.txt". The *.JS (JavaScript) extension of prefs.js is in antivirus
lists of suspect files to scan (like *.EXE, *.COM, and many others), probably
also in PC-cillin.

Of course, with the usual default preferences of antivirus software, the *.TXT
files are not in those lists, and therefore are not blocked by false positives
in real-time virus scan, which is running all the time (by default commonly)
with every file access attempt.

I still think Garret is probably right in comment 102, and antivirus programs
give sometimes the typical false positives, blocking the prefs.js file for
access in a so severe way that the current patch -although likely on the right
track- would be not enough for this bug, according to comment 133.

The possible log mentioned by Matti and Conrad in comment 134 and 135 seems to
be the natural way to verify if the cause (or causes) of the bug is this or/and
another one.


    
    

    
  
I tried to install PC Cillin several times but the installer fails.
(Without error message, it removes the partial installation)

    
    

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

    
  
No longer depends on: 123184

    
    

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

    
    

    
  
Hi Friends,

As it comes to the final Mozilla releases this bug seems to be lived up again.
I had agin a trunked prefs.js (2KB) today with an Mozilla 1.5a nighly build from
arround last week. :-)

Regards, Jan

    
    

    
  
Mine--Mozilla 1.5 Alpha--does the same thing, going through the initial setup
routine every time the browser is launched. All profile settings are lost as
well as start page, default status, etc. I don't know if this has been reported
or not, but every time I launch Mozilla or NS 7.1 I get this error message
exactly:   
An error occurred reading the startup configuration file. Please contact your
administrator. Prefs.js, SyntaxError: syntax error. (a=c)>//(f=iso-8859-1)

Hope this helps. I'm impressed otherwise. Keep up the good work.

    
    

    
  
I have build 2003071814, im not a programmer, i'm new to fixing these things.
This has started happenning to me in the past week. I tried different versions
1.4-1.5 and every time I close mozilla like everyone else all info is lost.
so instead of creating a new account every time,by typing in server and such i
imported settings and mail, which set up another account. I see this bug has
been fixed. well if someone could tell me which version its fixed in or how to
fix, Id appreciate it,like i have windows 98,outlook express..im not a software
writer and i m a beginnner learning how to read about fixing bugs,I'll try to
check out the patches and such-but if annyone can help or knows the solution pls
emaiil me bbaker4@maine.rr.com---Because I prefer mozilla mail--outlook makes me
put my admin password in every time
also i get the same error mess...cannot read config file contact admin-syntax error.
thanx---the patch's are greek to me.....
Flags: blocking1.4.x+

    
    

    
  
bbaker -- 

1) It sounds like you have a different bug than this.

2) Don't set blocking(+) unless you're part of drivers@mozilla.org. You can set
blocking(?), but there's no reason to for a RESOLVED FIXED bug.

-M
Flags: blocking1.4.x+

    
    

    
  
------- Additional Comments From bbaker4@maine.rr.com  2003-08-07 20:06 -------
I have build 2003071814, im not a programmer, i'm new to fixing these things.
This has started happenning to me in the past week. I tried different versions
1.4-1.5 and every time I close mozilla like everyone else all info is lost.
so instead of creating a new account every time,by typing in server and such i
imported settings and mail, which set up another account. I see this bug has
been fixed. well if someone could tell me which version its fixed in or how to
fix, Id appreciate it,like i have windows 98,outlook express..im not a software
writer and i m a beginnner learning how to read about fixing bugs,I'll try to
check out the patches and such-but if annyone can help or knows the solution pls
emaiil me bbaker4@maine.rr.com---Because I prefer mozilla mail--outlook makes me
put my admin password in every time
also i get the same error mess...cannot read config file contact admin-syntax error.
thanx---the patch's are greek to me.....


------- Additional Comments From maxka@ucsc.edu  2003-08-07 20:17 -------
bbaker -- 

1) It sounds like you have a different bug than this.

2) Don't set blocking(+) unless you're part of drivers@mozilla.org. You can set
blocking(?), but there's no reason to for a RESOLVED FIXED bug.

-M

Hi bbaker4 (i've mailed this reply to bbaker too)

This bug is a difficult one - it occurs/occured intermittently and sometimes not
for years.
Quite a lot of work was done on Mozilla for the 1.3 release to ensure that this
wouldn't happen any more, but the results back have been a bit inconclusive.

My worry with your report would be that your windows is infact a bit mushed.

Maybe you should get a copy of your prefs.js before and after the problem
happens - this might prove that you are having a different problem to this bug
which is quite specific.

There are no patches for you to use particuarly - the work done in the patches
is included in mozilla now as I understand it - if you are suffering this bug
the only thing to do is to keep a backup of prefs.js - but as I said, the
developers are reasonably convinced that this bug is fixed.

I haven't suffered from this bug myself since the work was done to fix it, but
as noone ever worked out what caused it, and as it always occured at random and
sometimes not for years, that dosen't prove very much.

I hope noone thinks I'm being too negative here - I'm as keen as anyone else to
see this bug buried forever.

Russell 
boblists@brightonart.org

    
    

    
  
bbaker4@maine.rr.com:
You see bug 193638. Please read that bug and fix your problem (comment #0)


    
    

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

    
    

    
  
My MOZ just did the same thing (bookmarks lost) on Win2K/SP3/LatestUpdates with
MOZ ver Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827,
and my variation is that I can't add anything to the personal toolbar and I
can't see the personal toolbar folder in the bookmark manager, even though it
toggles on/off ok from the View->Show/Hide menu.

Interestingly, the list of bookmarks that it has defaulted to is one from
atleast 1 year ago, WELL before I did a comprehensive bookmark re-org a few
months back. Only a few entries remain, and there is no sign of a backup
bookmarks file anywhere.

(I suspect) The crashes came from flakey TV capture card testing I did this week
that saw the box hard/fast reset several times.

sTu.

    
    

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

    
    

    
  
I am using Netscape 7.1 and I have experienced the dissapearing profile syndrom
several times. I think the prefs.js bug has not been solved.

I am using Mozilla on a Toshiba XP.

Will appreciate a solution to this problem.

Mtalo E. G.
mtalo@uclas.ac.tz

    
  
No longer depends on: startup

    
    

    
  
mass remove verifyme requests greater than 4 months old
Keywords: verifyme

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: