mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

safer inannex checking

Browse source 
git-annex-shell inannex now returns always 0, 1, or 100 (the last when
it's unclear if content is currently in the index due to it currently being
moved or dropped).

(Actual locking code still not yet written.)
This commit is contained in:
Joey Hess 2011-11-09 18:33:15 -04:00
parent 2934a65ac5
commit d3e1a3619f
14 changed files with 93 additions and 50 deletions
Download patch file Download diff file Expand all files Collapse all files

9
doc/bugs/cyclic_drop.mdwn
View file

@ -16,8 +16,8 @@ content and git-annex should refuse to do anything.
Then when checking inannex, try to take a shared lock. Note that to avoid
deadlock, this must be a nonblocking lock. If it fails, the status of
the content is unknown, so inannex should fail. Note that this needs to be
distinguishable from "not in annex".
the content is unknown, so inannex should fail. Note that this failure
needs to be distinguishable from "not in annex".
> Thinking about these lock files, this would be a lot more files,
> and would possibly break some assumptions that everything in
@ -52,6 +52,11 @@ The movee removes its copy.
So move --to needs to take the content lock on start. Then the inannex
will fail.
This is why it's important for inannex to fail in a way that is
distinguishable from "not in annex". Otherwise, move --to
would see the cycle as the remote not having content, and try to
redundantly send it, drop it locally, and still race.
--
move --from is similar. Consider a case where both the local and the remote