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
26.93 KB, text/plain
Details
patch v2
1.80 KB, 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) — — 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 — — 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: