218839 - Curently used addressbook is lost after adding new addressbook, due to incorrect ldap_2.user_id and undeleted ldap_2.servers.XYZ.position=0

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Description

[David Riker]

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

Comment 1

[WADA:World Anti-bad-Duping Agency]

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.

Comment 2

[WADA:World Anti-bad-Duping Agency]

Change summary for ease of search and understanging problem.

Comment 3

[WADA:World Anti-bad-Duping Agency]

I believe David is appropriate person because owner of bug 249613.

Comment 4

[WADA:World Anti-bad-Duping Agency]

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.

Comment 5

[Mark Banner (:standard8)]

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.

Comment 6

[David :Bienvenu]

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.

Comment 7

[WADA:World Anti-bad-Duping Agency]

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?  

Comment 8

[David :Bienvenu]

off the top of my head, I don't know.

Comment 9

[WADA:World Anti-bad-Duping Agency]

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.

Comment 10

[WADA:World Anti-bad-Duping Agency]

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 11

[WADA:World Anti-bad-Duping Agency]

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

Comment 12

[WADA:World Anti-bad-Duping Agency]

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.