I use the same profile and I can go back and forth between my two SM builds without loosing my password data in my profile, at least :-) [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090110 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/6acaaa957e0a +http://hg.mozilla.org/comm-central/rev/865f907bb16b) No bug. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090117 SeaMonkey/2.0a3pre] (experimental/_m-c_, home, optim default) (W2Ksp4) (http://hg.mozilla.org/mozilla-central/rev/a3abe1807f71 + bug 446300 patch +http://hg.mozilla.org/comm-central/rev/da4ab57196d6 + bug 446300 patch) The dialog displays only 2 of my 47 saved passwords. And the forms are not pre-filled on missing password sites either.
Is there a signons3.txt file in your profile? The toolkit login manager people might like to take a look at this and the signons.sqlite file.
(In reply to comment #1) > Is there a signons3.txt file in your profile? The toolkit login manager people > might like to take a look at this and the signons.sqlite file. It also creates it on the way to creating signons.sqlite. However, Serge, can you look in your profile at signons3.txt and signons.sqlite and see if they are the same date (within a few minutes/seconds I'd expect)? If they are not, then I think that signons3.txt may have been created a while ago when SeaMonkey initially tried building login manager but had conflicts. In any case, if you move signons3.txt and signons.sqlite out the way, it should reimport the passwords from signons.txt. If that doesn't fix it, then it would be worth enabling the signons.debug preference (set it to true), and getting a log of what happens when it upgrades the signons.txt file - a debug build may also be helpful here.
I'll test later, yet here are the files I currently have in that profile: signons.sqlite 17/01/2009 23:26 signons.txt (no) signons2.txt 06/08/2007 01:34 signons3.txt 17/01/2009 23:26 At first glance, the 3 files all have the "same" 2 entries.
Can you check the value of the signon.SignonFileName pref? I'm wondering if its <something>.s - if so that should be the file with 47 logins. (In reply to comment #3) > signons2.txt 06/08/2007 01:34 This date ties up with http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/toolkit/components/Makefile.in&rev=HEAD&mark=1.70#1.70 - Bug 304309 landed a patch to build with toolkit password manager and then backed it out again. Therefore my guess is that: - you ran one of those builds - it created signons2.txt - toolkit password manager then got backed out - wallet used signons.txt until a couple of days ago - we switched to toolkit password manager properly which choose to migrate signons2.txt (as that's the "newer" file). Why it only had two logins, not sure, but maybe you did only have two at that time (or there was some other error). Anyhow, hopefully you'll have a *.s file which does contain your signons, therefore I would suggest you move the other signons*.* out the way and let SM start up again, that way it should pick up the correct file. I think if that works we can close this bug as a wontfix - the original patch was only landed for about a week on nightly builds, those users that are affected the fix is simple, and we can publicise it on the newsgroup - it certainly doesn't seem worth trying to fix it.
(In reply to comment #2) > be worth enabling the signons.debug preference (set it to true), and getting a Ftr, 'signon.debug'. (In reply to comment #4) > <something>.s - if so that should be the file with 47 logins. Yep: signon.SignonFileName 12345678.s signon.SignonFileName2 signons2.txt signon.SignonFileName3 signons3.txt and 12345678.s 19/01/2009 01:50 > - we switched to toolkit password manager properly which choose to migrate > signons2.txt (as that's the "newer" file). I confirm the dependency: signons.sqlite <- signons3.txt <- signons2.txt <- 12345678.s. > Why it only had two logins, not sure, but maybe you did only have two at that > time (or there was some other error). Yeah, we won't go back to that time ;-) > I think if that works we can close this bug as a wontfix R.WontFix, then. Thanks for the detailed support !
Severity: normal → critical
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: regression → dataloss
Resolution: --- → WONTFIX
Summary: Only 2 of my 47 saved passwords are recognized by new Password Manager → Only 2 of my 47 saved passwords are recognized by new Password Manager, due to obsolete signons2.txt
Target Milestone: --- → seamonkey2.0a3
Ftr, whilst my SeaMonkey profile uses 12345678.s, my (4) affected Firefox profiles do have signon.SignonFileName signons.txt
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090119 SeaMonkey/2.0a3pre - Build ID: 20090119000439 Hm, interesting bug. It seems to explain why (or how) my mail passwords (for all four accounts) went away between 2009-01-12 and 2001-01-16 nightlies: linux:~/.mozilla/seamonkey/nexrdon9.default # ls -l sig* *.s -rw------- 1 root root 6513 2009-01-16 08:57 58696440.s -rw------- 1 root root 3357 2007-07-29 17:06 signons2.txt -rw------- 1 root root 3547 2009-01-16 19:27 signons3.txt -rw-r--r-- 1 root root 25600 2009-01-16 19:39 signons.sqlite signon.SignonFileName user set string 58696440.s signon.SignonFileName2 default string signons2.txt signon.SignonFileName3 default string signons3.txt I suspected (at the time) that the fact that the first mail username (as still shown in my Thunderbird2 profile) included an escaped dot (shown as %2E) might perhaps have been a factor. (That's my gmail username, corresponding to my present BMO email-address of record.)
You need to log in before you can comment on or make changes to this bug.