From b944da832b0433f3014396b2c7a53f1bd31f7c59 Mon Sep 17 00:00:00 2001
From: Joey Hess <joeyh@joeyh.name>
Date: Fri, 9 Oct 2015 15:59:42 -0400
Subject: [PATCH] tests and verified that the bug is fixed, in all the cases I
 identified

---
 Command/Drop.hs                                            | 6 +-----
 .../concurrent_drop--from_presence_checking_failures.mdwn  | 7 +++++++
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/Command/Drop.hs b/Command/Drop.hs
index d14cdad18e..5bbaf11c6b 100644
--- a/Command/Drop.hs
+++ b/Command/Drop.hs
@@ -20,8 +20,6 @@ import Annex.Content
 import Annex.Wanted
 import Annex.Notification
 
-import Utility.ThreadScheduler
-
 import System.Log.Logger (debugM)
 import qualified Data.Set as S
 
@@ -99,7 +97,7 @@ performLocal key afile numcopies preverified = lockContentForRemoval key $ \cont
 		( \proof -> do
 			liftIO $ debugM "drop" $ unwords
 				[ "Dropping from here"
-				, "proof: "
+				, "proof:"
 				, show proof
 				]
 			removeAnnex contentlock
@@ -125,8 +123,6 @@ performRemote key afile numcopies remote = do
 				, "proof: "
 				, show proof
 				]
-			liftIO $ print "waiting to drop.."
-			liftIO $ threadDelaySeconds (Seconds 10)
 			ok <- Remote.removeKey remote key
 			next $ cleanupRemote key remote ok
 		, stop
diff --git a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn
index 7b38af13c4..22e50766ae 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
 
 <pre>
@@ -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)
 
 <pre>
@@ -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,