[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails



I wrote:
> A back-ldif entry file only contain the entry's RDN, not the DN.
> (...)

Yup, that was it.  Different case in parent DNs.  This:

--- syncrepl.c	13 Nov 2008 21:46:49 -0000	1.421
+++ syncrepl.c	14 Nov 2008 09:29:30 -0000
@@ -3050,4 +3050,6 @@
 						dni->delOldRDN = 1;
 					}
+	Debug( LDAP_DEBUG_TRACE, "<<::syncrepl rename:%s:%s:%d:>>\n",
+		rs->sr_entry->e_dn, dni->new_entry->e_dn, dni->delOldRDN );
 					/* A ModDN has happened, but other changes may have
 					 * occurred before we picked it up. So fallthru to

shows these renames, with dni->delOldRDN = 1:

cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com
cn=James A Jones 1,ou=alumni association,ou=people,dc=example,dc=com

cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com
cn=Barbara Jensen,ou=information technology division,ou=people,dc=example,dc=com

Not sure what the right fix is.  ldif_back_modrdn() receives
op->orr_modlist already filled in with the cn="James A Jones 1" change.
Just use the awk variant to sort the attribute values in
tests/scripts/acfilter.sh?

What happens with syncrepl between two servers that do not spell DNs the
same - e.g. syncrepl from BDB to a backend which stores just the
normalized DN?

-- 
Hallvard