Am Donnerstag 15 April 2010 00:53:04 schrieb hyc@symas.com:

rhafer@suse.de wrote:

...

Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc@symas.com:

...

rhafer@suse.de wrote:

...

Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc@symas.com:

...

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.

It wasn't created without an entryCSN. It always had one. But the MOD to update the contextCSN (coming from the provider) doesn't contain one. So bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD operation. The easiest fix is probably to never touch the opattrs if "updatedn" is doing MODs, though I am not yet sure if it might break something. Currently my fix (not committed yet) only skips the slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN.

Ah, got it. Yes, sounds like your fix is fine.

Do you think it's fine to always skip slap_mods_opattrs() if "updatedn" is writing? Or should I check for contextCSN MODs specifically?

...

Historically the updatedn user (e.g. slurpd) has always provided all of the operational attributes in its updates.

I guess the question is what have we done in the past for updatedn writes? If we filled in missing opattrs, then we should continue to do so. So it should be a special case for contextCSN mods.

Ok, that's how the current fix work. So I think we are fine here now.