check if object is modified before starting to send it

Fix bug that caused some transfers to incorrectly fail with "content
changed while it was being sent", when the content was not changed.

While I don't know how to reproduce the problem that several people
reported, it is presumably due to the inode cache somehow being stale.
So check isUnmodified', and if it's not modified, include the file's
current inode cache in the set to accept, when checking for modification
after the transfer.

That seems like the right thing to do for another reason: The failure
says the file changed while it was being sent, but if the object file was
changed before the transfer started, that's wrong. So it needs to check
before allowing the transfer at all if the file is modified.

(Other calls to sameInodeCache or elemInodeCaches, when operating on inode
caches from the database, could also be problimatic if the inode cache is
somehow getting stale. This does not address such problems.)

Sponsored-by: Dartmouth College's Datalad project
This commit is contained in:
Joey Hess 2021-07-26 17:33:49 -04:00
parent ae015c2ab9
commit 3b5a3e168d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 43 additions and 10 deletions

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="joey"
subject="""comment 19"""
date="2021-07-26T21:20:15Z"
content="""
I've made it fall back to checking the file's content when the inode cache
is somehow stale. I expect this will solve the problem. But, I would still
like to know how to reproduce the problem, because if something is making
the inode cache go stale, this fallback check will need to hash the file,
which could make git-annex significantly more expensive.
"""]]