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
