This commit is contained in:
Joey Hess 2021-12-26 12:31:17 -04:00
parent 5ff55f622d
commit 575cd71ce4
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

@ -0,0 +1,34 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2021-12-26T16:17:43Z"
content="""
It looks rather like the full content of the file may already have been
downloaded, in `.git/annex/tmp/` which is why it "resumes"
from the end of the file.
But this does not necessarily look like a protocol problem. The protocol
handles no more data being sent. The failure is on the receiving side,
after it's received the data it indicates an overall failure.
One reason this could be happening is if the file in `.git/annex/tmp/` is
corrupted, so verifying the completed download fails.
I tried two experiements. First, I populated `.git/annex/tmp/` with a copy of
the annexed object file from the other repository. Then `git-annex get`
succeeded, and looked this this:
[2021-12-26 11:25:32.364107322] (P2P.IO) [ThreadId 4] P2P < GET 30 foo SHA256E-s30--8559e95c5b77e5e577466959d83097039d0d3f2b6a7e18b2fd5df0188ef648c6
[2021-12-26 11:25:32.365992548] (P2P.IO) [ThreadId 4] P2P > DATA 0
[2021-12-26 11:25:32.366778465] (P2P.IO) [ThreadId 4] P2P > VALID
[2021-12-26 11:25:32.394964731] (P2P.IO) [ThreadId 4] P2P < SUCCESS
Next, I did the same, but corrupted the tmp file. With that I reproduced
your problem exactly.
So, I suggest you try deleting files in `.git/annex/tmp/` and get them again.
I think that git-annex should probably try to recover from this by,
when verification of a downloaded file fails, deleting the tmp file.
But that will need some more thought.
"""]]