PR - Ticket - 49623-cont cenotaph errors on modrdn operations

[389-ds-bot]

Cloned from Pagure Pull-Request: https://pagure.io/389-ds-base/pull-request/50891

• Created at 2020-02-11 10:09:24 by lkrispen (@elkris)
• Merged at 2020-02-11 17:48:48

---

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: ?

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2020-02-11 15:26:15

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

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2020-02-11 15:45:35

Except that the patch looks good to me

[389-ds-bot]

Comment from lkrispen (@elkris) at 2020-02-11 16:00:35

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()

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2020-02-11 17:36:49

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

[389-ds-bot]

Comment from lkrispen (@elkris) at 2020-02-11 17:48:19

rebased onto 02d23f0

[389-ds-bot]

Comment from lkrispen (@elkris) at 2020-02-11 17:48:49

Pull-Request has been merged by elkris

[389-ds-bot]

Patch
50891.patch