From a243d6e6e9dcc657b5620244c3157da5c86406ec Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 9 Nov 2011 14:32:31 -0400 Subject: directly lock content? --- doc/bugs/cyclic_drop.mdwn | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/bugs/cyclic_drop.mdwn b/doc/bugs/cyclic_drop.mdwn index b43762e78..cc2943b7e 100644 --- a/doc/bugs/cyclic_drop.mdwn +++ b/doc/bugs/cyclic_drop.mdwn @@ -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. --- -- cgit v1.2.3