All users were logged out of Bugzilla on October 13th, 2018
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5.0a; hi, Mom) Gecko/2003071814 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5.0a; hi, Mom) Gecko/2003071814 I lost previos addressbook when I add new addressbook. I checked *.mab and contained my previous addressbook. Why? I have lots of abook*.map and *.map.backup. Why? Reproducible: Always Steps to Reproduce: 1.Open addressbook 2. add addressbook named Friend 3. add email address to friends. 4. Try to look for my personnel Folder. They are gone. Also look for other folders they are gone. I checked *.mab files contains the email addresses I added couple of days. Actual Results: Whne MOZ add new abook.mab, MOZ moved all previous email address to another abookx.mab. MOZ can not open them when I look for an saved email address. Expected Results: MOZ should implement abook.mab not recreate new one and save seperate abook.mab
Problem was re-created with latest-0.9 2004/12/01 build. Mechanism was as follows. (1) Mozilla/Thunderbird has problem of Bug 249613 - Deleting an address book sets a |ldap_2.servers.XYZ.position = 0| preference, instead of removing it. (2) MZ and TB does not update user_pref("ldap_2.user_id",XX) properly. (3) Due to (1) and (2), address book definition becomes like next if deletion of user address book was done in the past. user_pref("ldap_2.servers.user_directory_1.position", 0); user_pref("ldap_2.servers.user_directory_2.position", 0); user_pref("ldap_2.servers.user_directory_3.position", 0); user_pref("ldap_2.servers.user_directory_4.position", 0); user_pref("ldap_2.servers.user_directory_5.description", "ABOOK-4"); user_pref("ldap_2.servers.user_directory_5.filename", "abook-2.mab"); user_pref("ldap_2.servers.user_directory_6.position", 0); user_pref("ldap_2.servers.user_directory_7.description", "ABOOK-3"); user_pref("ldap_2.servers.user_directory_7.filename", "abook-3.mab"); user_pref("ldap_2.user_id", 4); (4) When new address book is added, next number to ldap_2.user_id is used. Then if currently active abook is defined as this entry, 5 in example, the entry will be overlayed, then it will be lost after restart. Note: Fortunately, current Mozilla/Thunderbird seems not to re-use already created abook-NN.mab file on new address book definition. So address book data is not lost since abook-NN.mab for overlayed entry is kept in profile directry. Manual recovery from the remaining ".mab" file is possible and simple work and not so difficult, although hard for usual users. Next three bugs look like above problem, but I do not know whether same or not. > bug-org 126633 : Whole addressbooks disappear from the Addressbook application > Bug-org 138160 : address books lost > Bug-org 220039 : Address book data loss David Riker, did you delete user defined address book in the past? See prefs.js and check above entries in prefs.js.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: major → critical
Change summary for ease of search and understanging problem.
Summary: Add new addressbook lost previous addressbook → Curently used addressbook is lost after adding new addressbook, due to incorrect ldap_2.user_id and undeled ldap_2.servers.XYZ.position=0
I believe David is appropriate person because owner of bug 249613.
Assignee: sspitzer → bienvenu
Summary: Curently used addressbook is lost after adding new addressbook, due to incorrect ldap_2.user_id and undeled ldap_2.servers.XYZ.position=0 → Curently used addressbook is lost after adding new addressbook, due to incorrect ldap_2.user_id and undeleted ldap_2.servers.XYZ.position=0
A reporter to BBS in Japan said "Renaming of existing address book was a workaround". I guess that rename sets user_pref("ldap_2.user_id",XX); properly again, user_pref("ldap_2.user_id",7); when step (3) in my comment #1.
David, although I realise there may still be a problem with locking - could this actually be our problem with the deletion of address books? (bug 299346) Comment 1 has some quite good instructions/explaination. I'll see what I can dig up later.
Mark, they could be related, I guess. No one here mentions the alert about the address book getting renamed, however (I don't know how new that is). If you get stuck, let me know and I'll look at this. The dir prefs stuff is a zoo.
prefs.js entry creation logic for abook seems to be changed already. Latest-trunk Thunderbird(2994/1014 build) created following entries when an abook is deleted and other abook is created. > user_pref("ldap_2.servers.ABOOK03.position", 0); > user_pref("ldap_2.servers.ABOOK03_1.description", "ABOOK-03"); > user_pref("ldap_2.servers.ABOOK03_1.dirType", 2); > user_pref("ldap_2.servers.ABOOK03_1.filename", "abook-7.mab"); And user_pref("ldap_2.user_id", NN); entry can not be seen in prefs.js. When a abook is deleted, ldap_2.servers.ABOOK03.position",0 is still kept, but when next creation, suffix of "_X" is added if entry already exists. Since ldap_2.user_id is not used any more, I think overlaying of entry won't occur. Another change. abook-N.mab file is not deleted when abook deletion, and re-used when new abook creation (abook-7.mab of ABOOK3_01 entry for address book of "ABOOK-03" in above examle.) This is changed behaviour from previous. (a) The file was not reused, and automatic backup of abook-N.mab on deletion was achieved by old logic. (b) Then many many abool-N.mab's were probably produced in prefs.js. I think reuse of abook-N.mab file is solution for above problem (b). David, do you know bugs for above changes?
off the top of my head, I don't know.
2994/1014 build => 2005/10/14 build (I'm not familiar with blind touch...) (In reply to comment #8) > off the top of my head, I don't know. No problem. I think we'll be able to close this bug as WORKSFORME after Tb 1.5 will be released, if no claim on this issue for several weeks or a few months at Forums and Bugzilla.
Number of abook(nn in ABOOKnn) looks to be decimal 2 digits, and suffix(X in "_X" looks to be a whole number. David, should we do some test cases addtionally? - Case-1 : When all of nn=01 to 99 is used. What will happen when 100th abook? - Case-2 : When X>=32268 ;-)
Comment #7 to Comment #10 are applicable to address book name with ASCII Alpha-numeric only. After TB 1.0.7, including current trunk nightly, Bug 316812 occurs if address book name doesn't contain ASCII Alpha-Numeric characters. (I don't know whether Tb 1.0.6 or previous has the problem or not.) This causes address book loss for users anytime if Japanese users use Japanese Character only for address book name. David, help me, please! I can't watch all forums or BBS'es in Japan, 365 days 24 hours, in order to help victims of Bug Bug 316812 in Japan...
We verified recently that ; - Tb 1.0 RC1 didn't have this bug's problem(not comment #1, same as comment #7). - Tb 1.0 RC1 had problem of Bug 316812. Bug 239714 looks to be who made the changes described in Comment #7. So I think this bug was fixed by patch of Bug 239714. (though Bug 316812 was born at the same time...) Changing to FIXED.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.