assistant: Fix bug that could cause direct mode files to be unstaged from git.
authorJoey Hess <joey@kitenet.net>
Tue, 2 Apr 2013 16:45:26 +0000 (12:45 -0400)
committerJoey Hess <joey@kitenet.net>
Tue, 2 Apr 2013 16:45:31 +0000 (12:45 -0400)
commit31cbde8190934bf868dc7953c627cdc20049d738
tree858bfbf6d3b2f11c7af75024b6774dc93dcb2772
parent5f4b9c5f8765f4aef5302e6977e05fed99d830ff
assistant: Fix bug that could cause direct mode files to be unstaged from git.

My test case for this bug is to have the assistant running and syncing to
a remote, and create a file in the annex. Then at the command line run
git annex drop. The assistant sees that the file is gone, sees it's a wanted
file, and downloads it from the remote.

With a directory special remote and a small file, I was seeing around 1
time in 3, a race where the file got unstaged from git after it got
downloaded.

Looking at what direct mode content managing code does in this case, it
deletes the symlink, and then adds the file content back. It would be
possible, sometimes, to avoid removing the symlink and do this atomically.
And I probably should.. but in some cases, particularly where the file
needs to be run through `cp` (multiple direct mode files with same
content), there's no way to atomically replace the symlink with the
content.

Anyway, the bug turns out to be something that the watcher does right for
indirect mode, but not for direct mode. When it got an add event, it
checked to see if this was a new file, or one we've already added. In the
latter case, no add event was queued. But that means that only the rm event
is queued, and so it unstages the file.

Fixed by queueing an add event even when the file is already in git.

Tested by running hundreds of drops in a loop; file remained staged.
Assistant/Threads/Watcher.hs
debian/changelog