Closed Bug 147822 Opened 22 years ago Closed 22 years ago

mozilla writes incomplete prefs.js

Categories

(Core Graveyard :: QuickLaunch (AKA turbo mode), defect)

Product:
Core Graveyard
Component:
QuickLaunch (AKA turbo mode)
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: bugzilla, Assigned: law)

References

Details

This is now the 5'th time Mozilla "forgets" all my mail&news settings and write an incomplete prefs.js file. It's kind of hard to reproduce. Perhaps it has something to with that I have my Mozilla profile on a MS network shared drive. Will try to find a way to reproduce... 20020528
Keywords: dataloss
I can now reproduce this everytime. 1. create a new profile 2. activate turbo 3. add a cyrus IMAP mail account 4. exit mozilla completly 5. add user_pref("mail.check_all_imap_folders_for_new", true); to the prefs.js 6. start mozilla mail 7. you get some mail server errors about mailbox not found 8. exit mozilla up til now everything is ok the prefs.js file now contain these two pref lines user_pref ("mail.server.server1.namespace.personal", "\"INBOX.\",\"INBOX.\",\"INBOX.\",\"I NBOX.\",\"INBOX.\""); user_pref("mail.server.server1.namespace.public", "\"\",\"\",\"\",\"\",\"\""); 9. exit turbo mozilla now write the incomplete prefs.js file. Could this be due to these two weird namespace prefs.js lines.
Severity: major → critical
Keywords: dataloss
sorry to say but this is a blocker. I can reproduce this everytime...:( weird stuff is going on with the writting of the prefs.js. first of all activate "quick launch". then try the following: 1. exit Mozilla completly 2. start the Mozilla browser (not mailnews) 3. exit mozilla 4. exit quick launch the prefs.js file is written in step 3 but not in step 4 now try this: 1. exit Mozilla completly 2. start Mozilla Mail & News 3. exit mozilla 4. exit quick launch the prefs.js file is written in step 3 AND in step 4 It's in this second write (step 4) that everything goes wrong and the prefs.js file in incomplete! Why is the second write done only with mail & news?
Severity: critical → blocker
Component: Preferences → QuickLaunch (AKA turbo mode)
really reassign
Assignee: ben → law
QA Contact: sairuh → gbush
I know that the fix for bug 98673 was recently checked in, making it so that now when you close all windows with Quick Launch enabled, Mozilla actually launches a new instance, then shuts down the first one, to close up any memory leaks. Might that have something to do with it?
The the new build 20020529 it's seems to have gone away. Will investigate futher....
Severity: blocker → normal
Blocks: profile-corrupt
Is this happening when the directory where prefs.js runs out of disc drive space? Does it also happen in other situations?
Summary: mozilla write incomplete prefs.js → mozilla writes incomplete prefs.js
just happend again with build 20020605. I have my profile on a Windows NT share drive and there are loads of space available on it. Having profiles on remote WinNT drives seems to be a no-go!
I have spent very little time looking into the prefs.js and other Mozilla system files, so can't provide much insight there, but I would like to state that I have been getting the same problem on a regular basis for a long time now (Mozilla forgets about me and gets me the new account wizard when I open the Mail app). I am on windows 2000, and have plenty of disk space (NTFS). I have never used quick launch. I usually don't go for daily builds, but when Henrik said that 20020529 seemed to fix the problem, I got the one for the day (my "about" currently returns Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020531). That didn't do it for me either; had a couple of crashes and in both cases Mozilla had forgotten about me when I restarted it. If it can be of help, one of these crashes was catched by the quality feedback agent, incident ID TB7106819G. Another clue that may be of help: After these recent crashes, and after reentering my POP server info in the account wizard, I close Mozilla so I can copy my inbox from the "bad" folder to the newly created one (I've pretty much given up trying to keep any kind of a local folders structure for now because of this problem). I always delete the .msf file in the new folder when I do that. Depending on how I do it, Mozilla will again give me the account wizard when I restart it: 1) If I copy both Inbox and Inbox.msf from the "bad" folder, it seems to consistently forget about me again on restart. 2) If instead of deleting the new empty Inbox and copying the old Inbox as a file, I open the empty Inbox and paste the contents of the old Inbox into it, it seems to work everytime so far (I don't copy Inbox.msf over). Could there be something to do with file creation date? 3) This is the weirdest, because it is not consistent. If I copy only the Inbox over, but not the Inbox.msf file, sometimes it works, and sometimes it forgets me again (I have just done it back to back: Got the problem, shut down Mozilla, copied Inbox over only, restarted mozilla, got the problem, set a new account again, closed mozilla, copied the previous Inbox over again (the exact same action I had just done), restarted mozilla, and this time it took (the email app openend without the wizard and displayed the contents of my "old" Inbox). Again, I don't know anything about the internals of Mozilla, but if the problem is a corruption of prefs.js, and if that can happen from time to time (sure seems to happen often to me), then in addition to trying to find the root causes of the corruption, wouldn't there be a way to have Mozilla automatically make backups of that and other key files, and try to recover from these backups if a corruption is detected (much like windows does with the registry)? That would at least permit a better partial recovery after a corruption than having to restart to enter all the settings by hand. BTW, I don't even have mail.server.server1.namespace entries in my prefs.js file.
Esther, Do you have any insights as to what might be happening here- especially the issues raised in comment #8? I could not reproduce Henrik's original problem but I am not sure if a cyrus IMAP mail account is equivalent to our IMAP (that was only diff I could see in my steps) I do not get the lines he mentions in my prefs.js file
In my case it seems to be related to having the profile stored on a Winnt drive. I'll try to investigate some more...
At least a dozen times with me on WinMe, latest 2002060808. (Understand that I use at least one new build per day.) And, after installation, the mail-news was fine. I had been playing with the ssl dll's xnews wants, preparatory to investigating that news client with secnews.netscape.com. I think I saw a flicker of the quick launch icon, I opened mail-news and got the wizard. BTW, my servers (all imap) are myrealbox, laposte.net, and my-mail.ch . I really do think I saw a flicker in advance -- could that have been an attempt to notify of new mail?
Just happened again. I knew it even before I opened MozMail- surprise, mail wizard awaited. There had just been the audio from Trillian alerting of a new mail arrived in Yahoo. It just has to have something to do with incoming alert packets. I'm closing Trillian now, cuz I'll be receiving this note in my Yahoo box!
Could everybody who experienced this bug, please report back and state: - did you have multiple profiles ? - did you have quick launch (turbo) one ? - is your profile located on local drive (C:) ? - is your PC fast or slow (300 P2 vs 800 P3) ?
Am responding to request for info as to system setup. I have a PIII 850, only 1 profile (Default User), C: drive is where I work (D: is sytem restore), normally I use quick launch. Only rarely would I not use quick launch so one cannot draw too much from my never having had the problem with ql not active.
My theory that incoming packets alerting of mail are involved seems refuted by the way it happened yesterday afternoon. I did notice that there was a long pause in the little quick lizard reappearing at the right. I'm wondering if the disappearing Java coffee cup is somehow related -- I'd thought that was an intended feature, but, perhaps not.
- did you have multiple profiles ? Only One - did you have quick launch (turbo) one ? Never - is your profile located on local drive (C:) ? Always - is your PC fast or slow (300 P2 vs 800 P3) ? Plenty fast (2.2 GHz P4)
- did you have multiple profiles ? Only One - did you have quick launch (turbo) one ? Always - is your profile located on local drive (C:) ? Yes - is your PC fast or slow (300 P2 vs 800 P3) ? AMD 1.4 I knew something was wrong when i visited a ssl page and mozill asked me if i was certain i wanted to do this: i knew i had cleared that checkbox forever ago. and, sure thing, fire up mail and news and it had lost all of my settings. winXP, NTFT, plenty of HD space
I experienced prefs.js lossage this morning on my Linux box running trunk build 2002071808 I started Mozilla and my start page, bookmarks, mail, everything were gone. I checked my profile directory and saw that all my files were as they should be, except prefs.js which was almost empty. It had about five lines in it. (Unfortunately I did not save a copy of what lines were there, I will do so if it happens again).
This is really an irksome bug and a critical one that needs fixed. I am running WinXP and am using the QuickLaunch deal - I have 1 gig of memory and an Athlon 2000 CPU. I've lost my mail/news/font settings for the 4th time - I thought it was related to machine reboot/power off/on, but I just confirmed it is not.
I've been seeing this - it is annoying - it overwrites prefs.js and prefs.bak - so I keep making sure I have a manual copy of the prefs to hand. It obviously overwrites my homepage settings and all mail settings, as well as the rest of the stuff in prefs.js. Using build 2002080108 with WinME. I only have a single profile. Turbo/QL is on - and it is while moz/ql is sitting there that the corruption seems to occur. Profile location is default for my WinME (NB the bug is not windows 2000 only) - windows/application data/mozilla/salt etc. I have recently upgraded from a 350Mhz CPU to 1.3 Ghz and seen it every few days on both systems. Never seen it on my linux boot. Never saw it before about 1.0 - but had it on probably all the recent nightlies. I think this should be a blocker for 1.1 release if it's showing up in 1.1 builds.
Same thing happens similar to bug #132517
Both this and bug #132517 are quite bad dataloss scenarios and should probably have the dataloss keyword and maybe a higher priority than normal. I have experienced this bug several times - leaving QL on overnight. Since switching off QL I haven't experienced this. I don't see mention of this dataloss with QL in the release notes - yet some trivial things like throbber still active even when page loaded on image rollovers gets a mention that is out of proportion to any problem. Heck, that sounds like a useless moan - what I should be asking is how could I go about adding the keyword that this bug deserves and where could I join efforts to discuss / edit release notes - now that's a more positive way to go ;-)
it seems as though bugs# 147822, 132517 and bug#95331 are addressing the same issues. The GOOD news, is that I think I've solved the mystery... which I added into the replies on # 95531. The problem is, the prefs.js file needs to be changed to a read-only file, when the preferences window isn't open, and in use. Somebody needs to write a program that will do this (I don't know how). I set my preferences, closed Mozilla, changed prefs.js to read-only (manually), and haven't suffered dataloss since. Of course, now I can't change preferences, clear the cache, etc... unless I "unlock" the file manually, either... and then lock it again. And there's always the risk of dataloss again, because when Mozilla shuts down, it could rewrite the prefs file, before I have a chance to switch it back to read-only. Hope This Helps, Mike.
After moving my profile from a MS Windows shared network drive to a local drive (C:) I haven't seen this bug.
From my experience and related bugs (95331, 155017, 155019): 1) It is not related to profile being on local or share drive, has happened on both. 2) It is not related to fast or slow system, has happened on both. 3) It is not related to mail alerts. I don't use Mozilla for mail (partly because of this bug) 4) prefs.js is not being written incompletely, a new empty account is being created which replaces the existing account and overwrites the prefs.js with defaults. Each time the bug happens I'm seeing a new .s file in the default profile directory and new News files. The old ones are still intact, just not pointed to by prefs.js. 5) This happens when the user either has not created a profile (only using the default profile) or has just created a new profile. Those of you who posted that you fixed the problem in some way other than write-protecting prefs.js can verify that you also created a non-default profile. 6) user.js is not overwritten, so can be used to retain settings. When I did not have user.js and only used the default profile, I had this frequently. Creating user.js or a non-default profile seems to fix the problem.
This would appear to be the same scenario as bug 155080 which has been fixed for some time. Would suggest it is marked fixed or duplicae of the later bug.
I'm inclined to agree that this has been fixed perhaps as a corollary of 155080. How else to explain so little chatter about it? Nobody who encountered it could be other than upset and irate. Rgds, Nigel L
I agree- have not seen problem of late
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
verified
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.