Re: index corruption problem (ITS#1349)

[Markus.Storm@mediaWays.net]

Pierangelo Masarati wrote:

[...]

> As I wrote you, there are chances the indices get polluted,
> including dn2id and id2entry, I guess, if the modify operation
> following the rdn modification fails (when the rdn is modified,
> the values used in the rdn are added to the related attributes
> also in the entry, and a special flag may also require the deletion
> of the old values).
> This operation may fail for a number of reasons, including acl
> checking, schema checking and so. This is what I mean when I say
> the operation should be considered unsafe, because there's no
> going back and the entry (and the index files) are left in a
> dangling state.
> 
> Note that concurrent modrdn calls are "nonsense", because
> as soon as one succeeds, the following ones will not find
> the entry they try to modify.
> 
> Pierangelo.


Although I consider this index corruption to be a bug (even though
- you're right - it's due to "misuse" of MODRDN), I think that the
way to go should be to avoid MODRDN for now and get back-bdb working.
This should ultimately avoid corruption.
Now how do we motivate Kurt do do that ? :)