diff options
author | Joey Hess <joeyh@joeyh.name> | 2015-10-09 18:03:00 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2015-10-09 18:03:00 -0400 |
commit | 2512faa6301603cfbda9706acb6b3670d3311e7f (patch) | |
tree | 2c07df8981953fb2dcf81abc0694648a34b44c87 /doc | |
parent | b65e678e7b557520be4b63eb0e91d88682e1dd42 (diff) | |
parent | bef58852d9b6150b0e2a47c412bd12dcc34a7794 (diff) |
Merge branch 'dropproof'
Diffstat (limited to 'doc')
-rw-r--r-- | doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn | 28 | ||||
-rw-r--r-- | doc/git-annex-shell.mdwn | 11 |
2 files changed, 39 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..66fe48896 100644 --- a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn +++ b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn @@ -2,6 +2,8 @@ Concurrent dropping of a file has problems when drop --from is used. (Also when the assistant or sync --content decided to drop from a remote.) +> Now [[fixed|done]] --[[Joey]] + [[!toc]] # refresher @@ -73,6 +75,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 +120,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 +204,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, @@ -339,3 +348,22 @@ A drops B keeps C keeps It can race other ways, but they all work out the same way essentially, due to the locking. </pre> + +# the bug, with moves + +`git annex move --from remote` is the same as a copy followed by drop --from, +so the same bug can occur then. + +But, the implementation differs from Command.Drop, so will also +need some changes. + +Command.Move.toPerform already locks local content for removal before +removing it, of course. So, that will interoperate fine with +concurrent drops/moves. Seems fine as-is. + +Command.Move.fromPerform simply needs to lock the local content +in place before dropping it from the remote. This satisfies the need +for 1 locked copy when dropping from a remote, and so is sufficent to +fix the bug. + +> done diff --git a/doc/git-annex-shell.mdwn b/doc/git-annex-shell.mdwn index d0e0930c5..73517ba89 100644 --- a/doc/git-annex-shell.mdwn +++ b/doc/git-annex-shell.mdwn @@ -43,6 +43,17 @@ first "/~/" or "/~user/" is expanded to the specified home directory. Exits 100 if it's unable to tell (perhaps the key is in the process of being removed from the annex). +* lockcontent directory key + + This locks a key's content in place in the annex, preventing it from + being dropped. + + Once the content is successfully locked, outputs "OK". Then the content + remains locked until a newline is received from the caller or the + connection is broken. + + Exits nonzero if the content is not present, or could not be locked. + * dropkey directory [key ...] This drops the annexed data for the specified keys. |