134994 - Replication keeps going into my personal address book

Status: VERIFIED FIXED

(MailNews Core :: LDAP Integration, defect, P1)

Description

[Scott MacGregor]

I have a test LDAP server in my profile called seamonkey.mcom.com. Every time i
try to replicate it, it ends up dumping a bunch of replicated entries into my
PAB. If I replicate again, my PAB gets yet another set of the same entries
dumped into it. So after every replication it grows by n where n is the # of
entries in the directory.

Comment 1

[Scott MacGregor]

Using a win32 release build: 2002032803

Comment 2

[Scott MacGregor]

Here are my prefs:

user_pref("ldap_2.servers.pab.filename", "abook.mab");
user_pref("ldap_2.servers.pab.replication.lastChangeNumber", 0);
user_pref("ldap_2.servers.seamonkey.description", "seamonkey");
user_pref("ldap_2.servers.seamonkey.filename", "abook.mab");
user_pref("ldap_2.servers.seamonkey.replication.lastChangeNumber", 0);
user_pref("ldap_2.servers.seamonkey.uri",
"ldap://seamonkey.mcom.com:389/o=mcom.com??sub?(objectclass=*)");

Seth says Rajiv checked in a fix for something similar to this. Is my build from
the 28th too old?

Comment 3

[(not reading, please use [e-mail] instead)]

re-assign to rdayal.

I can reproduce this as well.

There is code in there to prevent this scenario, but it doesn't seem to be 
working.

Comment 4

[(not reading, please use [e-mail] instead)]

even worse:

if you replicate again, I think you will lose your addresses in your pab.

replication does a "clean slate" on the .mab it uses, right Rajiv?

Comment 5

[yulian chang]

I saw the same problem with 04-02 build. Rajiv is looking into it.

Comment 6

[Scott MacGregor]

Yulian, did you intend to remove the mozilla 1.0 milestone, the P1 priority and
the dataloss keyword or was it just a merge conflict?  

Comment 7

[Rajiv Dayal]

the replication code calls nsDirPrefs to set the new server filename but it
seems it is not doing so, it does not use the leafName parameter passed to it
and generates a new filename only in case the DirSever::filename is null. Also
it is replicating and adding to the same replication file rather than clean
slate and then replicate since the CreateUnique creates a zero byte size file
and thus MoveTo fails.

Please find below the patch to fix the problems seen here.

Comment 8

[Rajiv Dayal]

Attachment: patch to fix the problem

Comment 9

[(not reading, please use [e-mail] instead)]

marking fixed.  the fix for this landed with #128087

Comment 10

[yulian chang]

Verified with 20020411 branch builds on various platforms.