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

plan to fix race

Browse source
This commit is contained in:
Joey Hess 2018-08-17 11:18:53 -04:00
parent 35e1697377
commit ec91b6e4b2
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 20 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
doc/todo/smudge.mdwn
View file

@ -12,6 +12,26 @@ git-annex should use smudge/clean filters. v6 mode
# because it doesn't know it has that name
# git commit clears up this mess
* If the user is getting a file that was not present, and at the same
time overwrites the file with new content, the new content can be staged
accidentially when git-annex runs git update-index on the file.
The race window size has been made fairly small, but still
varies with annex.queuesize, since it filters out modified files
before running git update-index on all queued files. A modification
that occurs after the filter checks the file triggers the race.
Here's how to prevent this race: Lock the index file before running git
update-index. Filter out worktree files that were modified already.
Run git update-index on a copy of the index so it runs despite the lock,
and once it's done, replace the old index with it and drop the lock.
Copying the index would be expensive. Could hard link it on systems that
support them.
Note that git split index files complicate this since there are other
files than the main index file.
* Checking out a different branch causes git to smudge all changed files,
and write their content. This does not honor annex.thin. A warning
message is printed in this case.
@ -47,19 +67,6 @@ git-annex should use smudge/clean filters. v6 mode
The git-annex proxy idea above could work around this problem.
* If the user is getting a file that was not present, and at the same
time overwrites the file with new content, the new content can be staged
accidentially when git-annex runs git update-index on the file.
The race window size has been made fairly small, but still
varies with annex.queuesize, since it filters out modified files
before running git update-index on all queued files. A modification
that occurs after the filter checks the file triggers the race.
To fully close this race would need a way to manually update the index
with the information git-annex knows, including the inode etc of the
worktree file.
### long term todos
* Potentially: Use git's new `filter.<driver>.process` interface, which will