From 3265c9d4a6e887bbaa22602438680cce876932b2 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 21 Sep 2015 13:29:59 -0400 Subject: forwarded bug --- ...g_after_a_sync_fails_because_network_is_down.mdwn | 2 ++ ...mment_1_aa4bf99c99b285ceb135fd7690257565._comment | 20 ++++++++++++++++++++ 2 files changed, 22 insertions(+) create mode 100644 doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn index 35e5111b6..332748123 100644 --- a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn +++ b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn @@ -41,3 +41,5 @@ My diagnosis is that when running `git annex sync testremote --content` when the (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config) failed + +> fowarded, so [[closing|done]] --[[Joey]] diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment new file mode 100644 index 000000000..597c017de --- /dev/null +++ b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2015-09-21T17:09:16Z" + content=""" +Analysis seems to make sense. Note that this happens only when gcrypt is +doing a push, not a pull, so there needs to be a local change made for the +sync to try to push out for the bug to occur. Reproduced by adding a file +and then syncing. + +It seems that gcrypt recovers fairly well; after setting the local +remote.foo.gcrypt-id to a new value, when the network comes back, it +re-sets it back to the real value next time a pull is made. Does this +bug result in any problem other than noise in the log? + +Anyway, it's certianly a gcrypt bug, and I don't see what git-annex can do +about it. Opened a bug there: + +Doesn't seem that this would be too hard to fix in gcrypt.. +"""]] -- cgit v1.2.3