The behaviour of modrdn for a tombstone entry is very inconsistent. Modrdn has two options: deleteoldrdn and newsuperior and the result is different for different combinations:
deleteoldrdn: 1 NO newsuperior: ==> err=53 (unwilling to perform)
deleteoldrdn: 1 newsuperior: <dn> ==> err=53 (unwilling to perform)
deleteoldrdn: 0 NO newsuperior ==> err=1 (operations error)
deleteoldrdn: 0 newsuperior: <dn> ==> CRASH
The crash has the side effect, that the entry is no longer accessable after restart, an attempt to repeat the operation gives err=32 (no such object)
1] Define the expected behaviour, consistent to all combinations. In my opinion tombstone entries are internal and direct modifications should be prevented, so err=53 seems appropriate.
2] Implement 1]
3] Investigate if there is a proper way to resurrect tombstones by a client
$ git merge bz974719
ldap/servers/slapd/back-ldbm/ldbm_modify.c | 7 +++++++
ldap/servers/slapd/back-ldbm/ldbm_modrdn.c | 7 +++++++
2 files changed, 14 insertions(+)
$ git push origin master
Counting objects: 15, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.45 KiB, done.
Total 8 (delta 6), reused 0 (delta 0)
c6a72a5..0c9e3b1 master -> master
fix backported to 1.2.11, 1.3.0 and 1.3.1
Metadata Update from @lkrispen:
- Issue assigned to lkrispen
- Issue set to the milestone: 220.127.116.11
to comment on this ticket.