#50891 Ticket - 49623-cont cenotaph errors on modrdn operations
Closed by spichugi. Opened by lkrispen.
lkrispen/389-ds-base t49623_2  into  master

Download 50891.patch

Bug: In modrdn operations a cenotaph entries are created to track the time when
an entry had existed. But in cases where rentries were renamed in cycles
reusing the dns again and again this failed with an error: "faild to add cenotaph"

Fix: Previous versions of cenotaphs with the same dn are not used (or maybe in very unlikely
scenarios) so there is no need to change the dn construction to be able to keep all
versions of the same cenotaph. Instead, if the creation of the cenotaph fails because
it already exists, the existin cenotaph is moodified with the lifespan data of the
cenotaph that was tried to add.

Reviewed by: ?

In case of failure to ADD, the entry cenotaph is not consumed. Should not it be freed ?

Except that the patch looks good to me

In case of failure to ADD, the entry cenotaph is not consumed. Should not it be freed ?

it is always consumed, see end of op_shared_add and comment before slapi_add_entry_internal()

You are right, it is freed systematically in op_shared_add. ACK

rebased onto 02d23f06d21576a3e4919dcabe6901840e05e500

Pull-Request has been merged by lkrispen

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3944

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.

Pull-Request has been closed by spichugi

Metadata