fix add overwrite race with git-annex add to annex

This is not a complete fix for all such races, only the one where a
large file gets changed while adding and gets added to git rather than
to the annex.

addLink needs to go away, any caller of it is probably subject to the
same kind of race. (Also, addLink itself fails to check gitignore when
symlinks are not supported.)

ingestAdd no longer checks gitignore. (It didn't check it consistently
before either, since there were cases where it did not run git add!)
When git-annex import calls it, it's already checked gitignore itself
earlier. When git-annex add calls it, it's usually on files found
by withFilesNotInGit, which handles checking ignores.

There was one other case, when git-annex add --batch calls it. In that
case, old git-annex behaved rather badly, it would seem to add the file,
but git add would later fail, leaving the file as an unstaged annex symlink.
That behavior has also been fixed.

Sponsored-by: Brett Eisenberg on Patreon
This commit is contained in:
Joey Hess 2022-06-14 13:20:42 -04:00
parent b471438c51
commit dd6dec4eb1
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 47 additions and 16 deletions

View file

@ -29,6 +29,14 @@ be that it's faster. It also sometimes relies on git add to check gitignore,
although sometimes redundandly, some of the callers of it may rely on that
and have to be changed to check it first themselves.
Since adding a file to the annex also involves locking it down and
detecting modifications made while generating the key, update-index is
sufficient.
> Update: This is done for `git-annex add`, using addSymlink. But addLink
> is still in use elsewhere, and those other users might also be subject to
> similar races.
When it's adding a file unlocked, it already stages the pointer file using
update-index instead so there is no overwrite problem there.
@ -44,5 +52,9 @@ added to the annex after all. Test case for this:
git-annex add
git diff --cached 1
Unsure how to fix this case yet?
Unsure how to fix this case yet? Maybe it needs to cache the inode,
hash the file content, then verifiy the inode did not change during
hashing, and then also use update-index.
--[[Joey]]