dp has experienced this as well... i've seen this occurring since, oh, the end of last week up to today's builds, on all three platforms. 0. let's say i start out with a master passwd set to 222. 1. the next day, i run through my usual installations: i use the InstallShield installer on winNT, but on linux and mac i just decompress the archives --i try to use the comm bits when they're available. 2. i fire up seamonkey. 3. i perform some task that requires my master passwd, such as: changing it, entering it when trying to adding usernam/passwd's to track, or even viewing signon info or wallet info. 4. when prompted for the master passwd, i enter 222 then click OK. result: i get a dialog saying that my passwd is incorrect, and would i like to try again? i click Yes. 5. i repeat step 4. still get the same result. could the [blah].k file be somehow corrupted btwn installations? or something else?

nominating for beta1. nor have i seen this occur a couple weeks back, so adding regression keyword too.

could this be related to bug 27910...?

I fixed a bug yesterday that affected the way the master password was encoded before being stored on disk. The bad encoding occured a few days earlier with an error that I made. So in essense the stored password file format has inadvertently changed from X to Y and back to X in the past week. If you had the original X format and then got a new build that required the Y format, it wouldn't recognize it. Likewise, after I fixed the bug, your file which now had the Y format would no longer work because I'm again expecting the X format. I'm pretty sure this is what you've run into. So I'm closing this out as fixed. If you can reproduce this problem in the future using builds from this day onward, then I'm all wrong and you should reopen this report.

reopening, after testing w/opt comm bits, 2000021708. still occurred on mac and NT, although i wasn't able to [mysteriously] repro on linux.

Can you do the following for me. 1. Prior to doing a new install, make a backup copy of your master password file (that's the one that ends in .k). 2. Run the old install first to make sure you can unlock the database successfully. 3. Do the new install 4. Make a second backup of the master key file 5. Run the new install and verify that it reports a mismatch when you try to unlock the database. 6. e-mail those two backups to me. Thanks.

I believe that sairuh creates new profiles everytime she installs. Right? If so, we can rule out the format change problem.

dp, that doesn't make sense. If she creates new profiles, then how could she be attempting to open her existing database -- she doesn't have any. Unless I'm completely not understanding what Sarah is saying, she is indeed reusing her old profile. But the format-change problem that you raise is interesting. That might be what Sarah is running into. Sarah, can you start with a completely new profile, create a database, and then see if you run into this problem the next time you reinstall? Also, it this completely reproducible -- i.e., does it happen every time after you reinstall?

In speaking with Sarah, I discovered the following: - The last time she saw this failure was on Wednesday which means she was using a database created with the Tuesday build and trying to open it with the Wednesday build. She has not seen the failure after installing either Thursday's build or today's (Friday's) build. - The change that I mentioned above which would account for her problem was made to wallet.cpp, version 1.68 which was checked in on Tuesday evening. (The log comment says it fixes a build warning, but that warning was hiding the problem that it actually was shifting too much and therefore encoding the output file incorrectly.) So this is all consistent with what I said previously. There was an inadvertent encoding change made which would make things encoded with Tuesday's build unreadable with Wednesday's build. That explains the problem that Sarah saw on Wednesday. Closing out once again as works-for-me (and works-for-sarah too as of yesterday), but with my fingers crossed. Please reopen again if this problem occurs again.

ugh. while this was not a problem on linux (using 2000021808 opt comm bits), it occurred on on mac, using the same bits. feh.

also double-checked on winNT (same bits) --and it's a problem there as well.

Wrong again. I just spoke with Sarah and indeed the files she was using in the cases that were failing were generated by browsers build prior to my change to wallet.cpp. She's now deleting all her old profiles on all platforms, both commercial and non-commercial. This should clear the problem up once and for all. If it comes back again, I'll buy her a free dinner in the moz cafeteria (all she can eat for up to $7). ;-) Closing out as works-for-me for hopefully the last time.

yep, having *.k files which are >16 feb 2000 makes all the difference. verifying.