474161 - Only 2 of my 47 saved passwords are recognized by new Password Manager, due to obsolete signons2.txt

Status: RESOLVED WONTFIX

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Serge Gautherie (:sgautherie)]

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.

Comment 1

[Philip Chee]

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.

Comment 2

[Mark Banner (:standard8)]

(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.

Comment 3

[Serge Gautherie (:sgautherie)]

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.

Comment 4

[Mark Banner (:standard8)]

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.

Comment 5

[Serge Gautherie (:sgautherie)]

(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 !

Comment 7

[Serge Gautherie (:sgautherie)]

Ftr,
whilst my SeaMonkey profile uses 12345678.s,
my (4) affected Firefox profiles do have
signon.SignonFileName  signons.txt

Comment 8

[Tony Mechelynck [:tonymec]]

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.)