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.