summaryrefslogtreecommitdiff
path: root/doc/bugs/cyclic_drop.mdwn
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-11-10 02:59:41 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-11-10 03:06:08 -0400
commite4105df78a9a12eaee7d1c00758854186c818931 (patch)
treeb87ba64795536d2fabe2c2dc99ff18f917f8eef1 /doc/bugs/cyclic_drop.mdwn
parent95704212510b525bf4fb3c76fc37043da26cb825 (diff)
tested all known types of cycles, all are fixed
My testing involved widening the race by adding sleeps, and making sure something sane happens in each case.
Diffstat (limited to 'doc/bugs/cyclic_drop.mdwn')
-rw-r--r--doc/bugs/cyclic_drop.mdwn22
1 files changed, 19 insertions, 3 deletions
diff --git a/doc/bugs/cyclic_drop.mdwn b/doc/bugs/cyclic_drop.mdwn
index beaaa6e35..296d61aac 100644
--- a/doc/bugs/cyclic_drop.mdwn
+++ b/doc/bugs/cyclic_drop.mdwn
@@ -3,6 +3,8 @@ 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.
+> Confirmed fixed now. All cases tested. [[done]]
+
---
Fixing this requires locking. (Well, there are other ways, like moving the
@@ -15,9 +17,10 @@ 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 failure
-needs to be distinguishable from "not in annex".
+deadlock, this must be a nonblocking lock. (Actually, with fcntl locking,
+can just check if there is a lock, without needing to take one.)
+If it fails, the status of 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
@@ -35,11 +38,18 @@ needs to be distinguishable from "not in annex".
>
> However, this would mean that such a hypothetical consumer could also
> make inannex checks fail.
+>
+> The other downside is that, for fcntl exclusive locking, the file has to
+> be opened for write. Normally the modes of content files are locked down
+> to prevent modifcation. Dealt with, but oh so nasty. Almost makes flock
+> locking seem worth using.
---
drop --from could also cycle. Locking should fix.
+> Confirmed fixed now.
+
---
move --to can also be included in the cycle, since it can drop data.
@@ -57,6 +67,8 @@ 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.
+> Confirmed fixed now.
+
--
move --from is similar. Consider a case where both the local and the remote
@@ -67,6 +79,8 @@ copies.
So move --from needs to take the content lock on start, so the inannex will
fail. NB: If the content is not locally present, don't take the lock.
+> Confirmed fixed now.
+
---
Another cycle might be running move --to and move --from on the same file,
@@ -82,6 +96,8 @@ is removed, so both the --to and --from see success and the --to proceeds
to remove the local content that the --from already caused to be removed
from the remote. So, no, the nasty exclusive lock is needed.
+> Confirmed fixed now.
+
---
Another cycle might involve move --from and drop, both run on the same