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

problem that came to me at 2 am

Browse source
This commit is contained in:
Joey Hess 2011-11-09 13:34:17 -04:00
parent 56b8194470
commit 393b6b1bde
1 changed files with 53 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

53
doc/bugs/cyclic_drop.mdwn Normal file
View file

@ -0,0 +1,53 @@
drop's verification that a remote still has content can fail
if the remote is also dropping the content at the same time. Each
repository checks that the other still has the content, and then both
drop it. Could also happen with larger cycles of repositories.
---
Fixing this requires locking. (Well, there are other ways, like moving the
content to a holding area when checking if it's safe to drop, but they
seem complicated, and would be hard to implement for move --from.)
Add per-content lock files. An exclusive lock is held on content when
it's in the process of being dropped, or moved. The lock is taken
nonblocking; if it cannot be obtained, something else is acting on the
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".
---
move --to can also be included in the cycle, since it can drop data.
Consider move to a remote that already has the content and
is at the same time doing a drop (or a move). The remote
verifies the content is present on the movee, and removes its copy.
The movee removes its copy.
So move --to needs to take the content lock on start. Then the inannex
will fail.
--
move --from is similar. Consider a case where both the local and the remote
are doing a move --from. Both have the content, and confirm the other does,
via inannex checks. Then both run git-annex-shell dropkey, removing both
copies.
So move --from needs to take the content lock on start, so the inannex will
fail.
---
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.
---
Another cycle might involve move --from and drop, both run on the same
file, locally. Again, the exclusive lock solves this.