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:
parent
ae015c2ab9
commit
3b5a3e168d
4 changed files with 43 additions and 10 deletions
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue