r...@openldap.org wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.208.247) > Submitted by: ralf > > > When using push-based replication (syncrepl-proxy) the entryCSN of the > consumer's server's suffix entry (the one that also holds the contextCSN > Attribute) is not in sync with the value on the provider. (Other operational > Attributes are out of sync as well) > > This is because the MOD Operation to update the contextCSN (sent by the > provider) does not contain any other operational Attributes. That causes the > consumer to add those attributes itself. > > I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not > calling slap_mods_opattrs() if the updatedn modifies "contextCSN") > But how did the suffix entry get created without an entryCSN in the first place? The MOD that updates the contextCSN doesn't happen until after the suffix entry already exists.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
