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?