Open Bug 322738 Opened 14 years ago Updated 4 years ago
Adding email account results in "... user name and server name already exists ..."
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Obsolete data, in particular email user/server name pairs, are carried forward in the prefs.js file, even though the account/s may have been long ago deleted. So even though the account does not appear in the mail client, the account manager prevents them from being re-added; thus triggering the "name already exists" message. This problem appears in both Mozilla suite and Thunderbird 1.0.7 Reproducible: Didn't try Steps to Reproduce: Try to set new or current user name and server name that seems "new", in that is doesn't appear as an email account in the GUI window, but has old entries for that user/server name pair in the prefs.js file. Actual Results: Received error message "An account with that user name and server name already exists. Please enter a different user name and/or server name" Expected Results: Should have been able set or create that user/server name pop account setting. This is related to bug# 238006. It's also similar to a discussion on mozillaZine posted 1/31/05 (almost a year ago): http://forums.mozillazine.org/viewtopic.php?t=210909&highlight=&sid=736675bd6012be0f804eff6782bc31d9 In fact, that discussion allowed me to solve the problem. "rick1matthews" suggested one should hand edit the prefs.js to remove the old user/server name data. So, bottom line is that Mozilla/Thunderbird need to ensure consistent state between prefs.js entries and actual account information.
I don't hit this bug by simply adding an account, deleting it and re-adding it. Do you know how your prefs got into the state of having deleted accounts?
Version: unspecified → 1.8 Branch
(In reply to comment #1) > I don't hit this bug by simply adding an account, deleting it and re-adding it. > Do you know how your prefs got into the state of having deleted accounts? > I'm sorry I don't know precisely how it happened, but I believe it's related to having more than one account on the same pop server. Even though I only have two active accounts, my prefs.js file has 4 entries for mail servers. That is, there are 4 entries of the type user_pref("mail.server.server#.xxxxxxx"), and user_pref("mail.identity.id#.xxxxxxx").
SeaMonkey v1.0.x is not supported anymore. Can you reproduce with SeaMonkey v1.1.9 ?
Version: 1.8 Branch → SeaMonkey 1.0 Branch
Yes, the problem occurs with SeaMonkey V1.1.11. But, it's funny: I THOUGHT this bug was "confirmed", understood, and was well on its way to being fixed; because "Bug 352801 – 188.8.131.52 keeps asking for password" (https://bugzilla.mozilla.org/show_bug.cgi?id=352801) was caused by the same problem. Even though they seems unrelated, in that bug as here, the problem is that Thunderbird and SeaMonkey act oddly (OK, admittedly oddly from the USER'S perspective) if there are any inactive and/or deleted email accounts that still have partial entries in the user's prefs.js. From Bug 352801: David Bienvenu 2006-09-27 08:08:09 PDT [the problem is that in the prefs.js, there were] two pop3 servers with the same user name and hostname - server1 and server3, which correspond to account 1 and account 3. This effectively hid server3 from the UI, which can only display unique server uri's because of RDF. So I think the corruption was that somehow we allowed the duplicate account to get created. But the code that checks for new mail has no such restriction - it's happy to check server3 for new mail... In that case, it was the 'check mail' code that choked on duplicate servers; while in this case, it's the 'account manager' that gets confused, and so complains that the "user name and server name already exists". But, in both cases, the catch is that the UI (user interface) doesn't show the duplicate server data, and so the user has no way to delete, or even see that the duplicate exists! That's not something I'd call user friendly. Now clearly, there is no way to guarantee that the prefs.js doesn't have duplicate or otherwise 'incorrect' data in it: If one uses SeaMonkey and Thunderbird long enough, the entropy will creep in. So as I said before, way back in January 2006, "Mozilla/Thunderbird/SeaMonkey should ensure a consistent state between the prefs.js entries and actual account information." And barring that, at LEAST the User Interface should be able to DISPLAY the account information in the prefs.js, including duplicates, partial entries, and any other "warts", so that the user might have a chance in h*ll of finding and fixing the problem!
I have the same bug in Thunderbird on a new computer. I just get the message that the account already exist. How do I fix it?
I never saw that problem with SeaMonky
You need to log in before you can comment on or make changes to this bug.