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

directly lock content?

Browse source
This commit is contained in:
Joey Hess 2011-11-09 14:32:31 -04:00
parent 393b6b1bde
commit a243d6e6e9
1 changed files with 18 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
doc/bugs/cyclic_drop.mdwn
View file

@ -19,6 +19,23 @@ 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".
> Thinking about these lock files, this would be a lot more files,
> and would possibly break some assumptions that everything in
> `.git/annex/objects` is a key's content. (Or would need lots more
> directories to put the lock files elsewhere.) There would be more
> overhead to manage these and have them on disk.
>
> What if it just locked the actual content file? The obvious limitation
> is only content that was already inannex could be locked, but that
> happens to be exactly what's needed here; if content is not present,
> it's not going to get dropped or moved.
>
> Of course, if some consumer of a file locked it, then it could prevent it
> from being dropped or moved. This could be considered a bug, or a feature. :)
>
> However, this would mean that such a hypothetical consumer could also
> make inannex checks fail.
---
move --to can also be included in the cycle, since it can drop data.
@ -39,7 +56,7 @@ 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.
fail. NB: If the content is not locally present, don't take the lock.
---