diff options
author | Joey Hess <joey@kitenet.net> | 2011-11-09 22:15:33 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2011-11-09 22:15:33 -0400 |
commit | a218ce41cfef19f306ca462fb5d57c6647a680e2 (patch) | |
tree | b38795d2ce2731e69fc368d4ec7a6f66281a057d /doc/bugs/cyclic_drop.mdwn | |
parent | cf0174c922e4a4f473a846ec0488ea4011ab500c (diff) |
exclusive locks, ugh
Diffstat (limited to 'doc/bugs/cyclic_drop.mdwn')
-rw-r--r-- | doc/bugs/cyclic_drop.mdwn | 9 |
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 |