rein@OpenLDAP.org wrote:

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein

Syncrepl fails to update an entry if the objectClass was replaced with a new set of values that explicitly lists a superior that was only implicitly present in the old entry.

I have only seen this during the present phase of replication, so I don't know if it can happen during persistent update as well. It probably worked for me in the persistent phase as the entire entry was deleted and added again there.

The patch at the end always uses replace instead of delete/add of the objectClass values. Is this OK Howard? Or is it necessary to perform further analysis of which values to add/delete?

It's probably OK. Doing specific add/delete is better from an indexing performance point of view.

... ITS#5517 is really starting to annoy me ...

Rein Tollevik Basefarm AS

Index: syncrepl.c

RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v retrieving revision 1.1.1.31 diff -u -u -r1.1.1.31 syncrepl.c --- syncrepl.c 6 Jul 2008 12:23:53 -0000 1.1.1.31 +++ syncrepl.c 7 Jul 2008 19:21:57 -0000 @@ -2883,6 +2883,14 @@ } }

• /* Don't delete/add an objectClass, always use the replace op.
  

•  * Modify would fail if provider has replaced entry with a new,
  

•  * and the new explicitly includes a superior of a class that was
  

•  * only included implicitly in the old entry.  Ref ITS#5517.
  

•  */
  

• if ( nn&&  no<  o&&  old->a_desc == slap_schema.si_ad_objectClass )
  

• 	no = o;
  

• i = j; /* all old values were deleted, just use the replace op */ if ( no == o ) {