> It's not clear to me where the issue is. What is the "right" sequence the > add of the new superior and the mordrdn should be transmitted? Should the > provider operate differently, or should the consumer check all syncrepl > messages and try to rebuild the final state, instead of giving up when the > internal lookup for the newsuperior fails? Probably, a workaround could > be to perform the modrdn by crating the new superior as a glue object, > which eventually will be replaced by the actual add.
I've quickly hacked things this way, and it seems to work fine. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-17-sync-rename.1.patch> Please let me know if this approach is sound enough, I might have overlooked some implications. p.
