summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-11-09 22:15:33 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-11-09 22:15:33 -0400
commita218ce41cfef19f306ca462fb5d57c6647a680e2 (patch)
treeb38795d2ce2731e69fc368d4ec7a6f66281a057d /doc
parentcf0174c922e4a4f473a846ec0488ea4011ab500c (diff)
exclusive locks, ugh
Diffstat (limited to 'doc')
-rw-r--r--doc/bugs/cyclic_drop.mdwn9
1 files changed, 9 insertions, 0 deletions
diff --git a/doc/bugs/cyclic_drop.mdwn b/doc/bugs/cyclic_drop.mdwn
index 7804380ae..beaaa6e35 100644
--- a/doc/bugs/cyclic_drop.mdwn
+++ b/doc/bugs/cyclic_drop.mdwn
@@ -73,6 +73,15 @@ Another cycle might be running move --to and move --from on the same file,
locally. The exclusivity of the content lock solves this, as only one can
run at a time.
+Would it work with a shared lock? The --to would run git-annex-shell
+inannex. The --from would also be running, and would run git-annex-shell
+dropkey. So inannex and dropkey would end up running on the remote
+at the same time. Dropkey takes the content lock, and inannex checks it,
+but what if inannex runs first? Then it returns true, and then the content
+is removed, so both the --to and --from see success and the --to proceeds
+to remove the local content that the --from already caused to be removed
+from the remote. So, no, the nasty exclusive lock is needed.
+
---
Another cycle might involve move --from and drop, both run on the same