summaryrefslogtreecommitdiff
path: root/third_party/waf/waflib/Tools/ruby.py
diff options
context:
space:
mode:
authorStefan Metzmacher <metze@samba.org>2019-03-11 14:52:57 +0100
committerAndrew Bartlett <abartlet@samba.org>2019-03-14 02:12:19 +0000
commit5357f591accffbf8c62335c308b985811b66f0b5 (patch)
tree3e8261a81ffa1539dab64dcffbddaefff5d43938 /third_party/waf/waflib/Tools/ruby.py
parent8ba6f1c895ee9b6b592578f21e7f79ed36236bef (diff)
downloadsamba-5357f591accffbf8c62335c308b985811b66f0b5.tar.gz
blackbox/dbcheck-links.sh: reproduce lost deleted object problem
When a parent object is removed during the tombstone garbage collection before a child object and samba-tool dbcheck runs at the same time, the following can happen: - If the object child had DISALLOW_MOVE_ON_DELETE in systemFlags, samba-tool dbcheck moves the object under the LostAndFound[Config] object (as an originating update!) - The lastKnownParent attribute is removed (as an originating update!) These originating updates cause the object to have an extended time as tombstone. And these changes are replicated to other DCs, which very likely already removed the object completely! This means the destination DC of replication has no chance to handle the object it gets from the source DC with just 2 attributes (name, lastKnownParent). The destination logs something like: No objectClass found in replPropertyMetaData BUG: https://bugzilla.samba.org/show_bug.cgi?id=13816 Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Andrew Bartlett <abartlet@samba.org>
Diffstat (limited to 'third_party/waf/waflib/Tools/ruby.py')
0 files changed, 0 insertions, 0 deletions