summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2015-10-09 15:59:42 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2015-10-09 15:59:42 -0400
commite3eb0165dfec73d065b409d14ac83f855384b56b (patch)
tree5babf7cc23722e2436882355f4d5437a40f3a81e /doc
parent3c43af79d56a25bfff3eae1c1342c9a308223347 (diff)
tests and verified that the bug is fixed, in all the cases I identified
Diffstat (limited to 'doc')
-rw-r--r--doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn7
1 files changed, 7 insertions, 0 deletions
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
<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,