From: Joey Hess Date: Mon, 26 Jul 2021 17:59:07 +0000 (-0400) Subject: comment X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~2^2^2~69^2~34 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=6bbd606390737f7f39a07c65612fdfe4fa048f6c;p=git-annex.git comment --- diff --git a/doc/bugs/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._comment b/doc/bugs/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._comment new file mode 100644 index 0000000000..bb730f9ce2 --- /dev/null +++ b/doc/bugs/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._comment @@ -0,0 +1,27 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 17""" + date="2021-07-26T17:12:28Z" + content=""" +I can certianly reproduce this if I manually get the keys database +into a state where it has the wrong inode recorded for the object file. + +I have not found a way to make that happen using git-annex, but I'm +guessing it might involve annex.thin being set, and almost certianly +involves unlocked files. Some sequence of events is happening in +the git repo that later prevents getting content from it, even though +the content is still there. + +It kind of looks like Command.Lock might neglect to update the keys +database when it repopulates the annex object from an unmodified associated +file in the case where it was hard linked to another, unlocked file and so +got modified. I have not quite managed to make that reproduce it though. + +But that's just guessing and the real situation could be something +different. Someone needs to figure out how to reproduce this, +until then I'm probably stuck. + +(Enough other things could break due to this kind of database inconsistency +that simply removing the check when transferring the file would only paper +over the problem.) +"""]]