From e3eb0165dfec73d065b409d14ac83f855384b56b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 9 Oct 2015 15:59:42 -0400 Subject: tests and verified that the bug is fixed, in all the cases I identified --- doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/bugs') diff --git a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn index 7b38af13c..22e50766a 100644 --- a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn +++ b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn @@ -73,6 +73,8 @@ as part of its check of numcopies, and keep it locked while it's asking B to drop it. Then when B tells A to drop it, it'll be locked and that'll fail (and vice-versa). +> Done, and verified the fix works in this situation. + # the bug part 2 
@@ -116,6 +118,8 @@ Note that this is analgous to the fix above; in both cases
 the change is from checking if content is in a location, to locking it in
 that location while performing a drop from another location.
 
+> Done, and verified the fix works in this situation.
+
 # the bug part 3 (where it gets really nasty)
 
 
@@ -198,6 +202,9 @@ never entirely lost.
 Dipping below desired numcopies in an unusual race condition, and then
 doing extra work later to recover may be good enough.
 
+> Implemented, and I've now verified this solves the case above.
+> Indeed, neither drop succeeds, because no copy can be locked.
+
 ### to drop from local repo
 
 When dropping an object from the local repo, lock it for drop,
-- 
cgit v1.2.3