add content retention files
This allows lockContentShared to lock content for eg, 10 minutes and if the process then gets terminated before it can unlock, the content will remain locked for that amount of time. The Windows implementation is not yet tested. In P2P.Annex, a duration of 10 minutes is used. This way, when p2pstdio or remotedaemon is serving the P2P protocol, and is asked to LOCKCONTENT, and that process gets killed, the content will not be subject to deletion. This is not a perfect solution to doc/todo/P2P_locking_connection_drop_safety.mdwn yet, but it gets most of the way there, without needing any P2P protocol changes. This is only done in v10 and higher repositories (or on Windows). It might be possible to backport it to v8 or earlier, but it would complicate locking even further, and without a separate lock file, might be hard. I think that by the time this fix reaches a given user, they will probably have been running git-annex 10.x long enough that their v8 repositories will have upgraded to v10 after the 1 year wait. And it's not as if git-annex hasn't already been subject to this problem (though I have not heard of any data loss caused by it) for 6 years already, so waiting another fraction of a year on top of however long it takes this fix to reach users is unlikely to be a problem.
This commit is contained in:
parent
badcb502a4
commit
d2b27ca136
8 changed files with 205 additions and 29 deletions
|
@ -472,7 +472,7 @@ lockKey' repo r st@(State connpool duc _ _ _) key callback
|
|||
-- and then run the callback in the original
|
||||
-- annex monad, not the remote's.
|
||||
onLocalFast st $
|
||||
Annex.Content.lockContentShared key $
|
||||
Annex.Content.lockContentShared key Nothing $
|
||||
liftIO . inorigrepo . callback
|
||||
, failedlock
|
||||
)
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue