From 6bbd606390737f7f39a07c65612fdfe4fa048f6c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 26 Jul 2021 13:59:07 -0400 Subject: [PATCH] comment --- ..._7c7b953b2366fbfc1b95cc6048473ddb._comment | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 doc/bugs/__34__failed_to_send_content_to_remote__34__/comment_17_7c7b953b2366fbfc1b95cc6048473ddb._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.) +"""]] -- 2.30.2