User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7.10) Gecko/20050717 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.7.10) Gecko/20050717 Firefox/1.0.6 problem appeared after adding another account with the same email adress. I've needed to check if my settings for account are ok (after win reinstall). Old messages was imported and I wanted them to stay, so I've changed username and server for account, after that I've added account again (leaving old with wrong settings, but the same email name) The result was new account didn't appeared in folder pane and even was not visible in Tools->account config, but - interesting - information was written "somwhere", becouse I could not reverse settings in "old" account (TB said there is such account already). Anyway, only "old" account was visible, there was no way to find/change settings for newly created one. The only solution I've found (have no time for bugs;-) was to delete "old" account (losing mails); then "new" account appeared. this bug seems to be similiar to: https://bugzilla.mozilla.org/show_bug.cgi?id=238006 Reproducible: Always Steps to Reproduce: 1. create email account and retrieve mails 2. change username and server leaving email name untouched 3. add account again Actual Results: new account will not be shown in folder pane and in Tools->Account config, only old account is visible. you cannot neither change setting for old account nor change / delete new (it's hidden). it means you cannot reverse setings in old account and use it. you can only delete old account loosing your mails. Expected Results: Old and new accounts should be visible in TB folder pane and tools->Acoount config menu.
*** Bug 303543 has been marked as a duplicate of this bug. ***
I can confirm. Thunderbird version 18.104.22.168 (20080708) Reproducible: Always Steps to Reproduce: 1. create email account 2. change server hostname, close account dialog 3. add account again Problem: When you change the hostname mail.server.server#.realhostname is set to new hostname and mail.server.server#.hostname is left to old value. Workaround: Setting mail.server.server#.hostname to be equal to mail.server.server#.realhostname makes both accounts appear. Questions: Why is there a hostname and realhostname? Are they supposed to be different?
(I think reporter is gone)
(In reply to comment #2) > Questions: > Why is there a hostname and realhostname? Are they supposed to be different? Yes. See Bug 376001 Comment #3. > Problem: > When you change the hostname mail.server.server#.realhostname is set to > new hostname and mail.server.server#.hostname is left to old value. It can't be say as "real problem", I think. hostname/userName is used internally in many places and current implementation can not handle hostname/userName value change. So realhostname/realuserName was introduced in case of host name change/user name change after initial account definition. I think problem is in dulplicate check. Account-1 : Initially defined with Host1/User1, then changed to HostX/UserX hostname =Host1 / userName =User1 realhostname=HostX / realuserName=UserX Account-2 : Defined with Host1/User1 => hostname=Host1/userName=User1 is used => Duplicate check is probably done against ; Account-1's realhostname+realuserName(HostX+UserX) Account-2's hostname+userName(Host1+User1) I think duplicate check should be executed against all of hostname+userName and realhostname+realuserName. Problem is re-created with Tb trunk -> Confirming. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) > Gecko/20081125 Shredder/3.0b1pre
FYI. See Bug 274027 for "mail.server.server#.hostname is left to old value".
Behaviour of Tb trunk was slightly different from Tb 22.214.171.124. Tested with next entries for already defined account. > user_pref("mail.account.account3.identities", "id3"); > user_pref("mail.account.account3.server", "server3"); > user_pref("mail.identity.id3.useremail", "firstname.lastname@example.org"); > user_pref("mail.server.server3.hostname", "xxx.xxx.xxx"); > user_pref("mail.server.server3.userName", "xxx"); > user_pref("mail.server.server3.realhostname", "x3.x.x"); > user_pref("mail.server.server3.realuserName", "x3"); Note: In order to get same N for accountN/idN/serverN for ease of test, number assigned to "Local Folders" (X of account.accountX/server.serverX) is changed to 9999 in prefs.js. (1-A) Tb 126.96.36.199 generated next entries, upon new account definition with hostname=xxx.xxx.xxx, userName=xxx. > user_pref("mail.account.account4.identities", "id4"); > user_pref("mail.account.account4.server", "server4"); > user_pref("mail.identity.id4.useremail", "email@example.com"); > user_pref("mail.server.server4.hostname", "xxx.xxx.xxx"); > user_pref("mail.server.server4.name", "firstname.lastname@example.org"); > user_pref("mail.server.server4.type", "pop3"); > user_pref("mail.server.server4.userName", "xxx"); > (no other mail.server.server4.???? was created by Tb) Directory for this server3 was not created, and entries of directory & directory-rel were not generated. (1-B) Tb trunk generated next entries and some other entries in prefs.js, in addition to above entries in (1-A), upon new account definition with hostname=xxx.xxx.xxx, userName=xxx. > user_pref("mail.server.serverN.directory", "C:\\...\\xxx.xxx-1.xxx"); > user_pref("mail.server.server6.directory-rel", "[ProfD]Mail/xxx.xxx-1.xxx"); And created directory of "...\xxx.xxx-1.xxx". (2-A) Tb 188.8.131.52 didn't display this new account (mail.account.accountN.server points "server4") in Folder Pane nor Account Settings panel. (2-B) Tb trunk(2008/12/04 build) displayed the new account in Folder Pane and Account Settings panel, but all of displayed data was data of already defined account(account.account3/identity.id3/server.server3). And, upon account's settings change, even at account which should be account4, entries for account/account3 was updated. > user_pref("mail.identity.id3.useremail", "email@example.com"); > user_pref("mail.server.server3.realhostname", "x999.x.x"); > user_pref("mail.server.server3.realuserName", "x999"); Settings for account4/id4/server4 was not modified. (3) Because server.server4.hostname=xxx.xxx.xxx and server.server4.userName=xxx already exist, no new account with hostname=xxx.xxx.xxx and userName=xxx dut to duplicate check.
(In reply to comment #8) > dup then? It's up to you(triage team) or member of Mozilla Messaging Company(who is responsible to "Thunderbird").
(In reply to WADA from comment #4) > Account-1 : Initially defined with Host1/User1, then changed to > HostX/UserX > hostname =Host1 / userName =User1 > realhostname=HostX / realuserName=UserX > Account-2 : Defined with Host1/User1 > => hostname=Host1/userName=User1 is used > => Duplicate check is probably done against ; > Account-1's realhostname+realuserName(HostX+UserX) > Account-2's hostname+userName(Host1+User1) > I think duplicate check should be executed against all of hostname+userName > and realhostname+realuserName. Ok, so what do we do when a duplication is found? We can't change username/hostname of the first account. Do we create the new account with modified login data? E.g. username = User1-1, hostname = Host1 and realUserName = User1 ? Or do you suggest to modify the hostname? The local directory is already modified in case of duplicate hostnames so we get e.g. /mail.com and /mail-1.com.
Well, we could just refuse to create the account... I don't know what Thunderbird's new code does in this case.
We could, but that would confuse the user and also would be a bug as the new login data is completely valid. If currently no account has the same login (realuser/realhost) then we must allow it in some way. Is it a problem if we mangle the username and put the real user name into realUsername straight at creation time?
(In reply to :aceman from comment #14) > Ok, so what do we do when a duplication is found? > We can't change username/hostname of the first account. It's very simple. (i) Do proper duplication check on any of hostnae+userName and realhostname+realuseName upon account creation, in order that this bug won't occur again any more. (ii) If duplicated accounts due to this bug is detected, notify user about it, then request user to delete the wongly generated and dup accont(s), and request user to re-defie accoutn(s) with Tb which doesn't have this bug.