From 0a0242224d9b2b5e215805103643e5a2faae4eb9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 5 Nov 2018 18:25:55 -0400 Subject: [PATCH] full analysis --- ..._a3d803f25795365c9651d2ec023d9145._comment | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/bugs/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment diff --git a/doc/bugs/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment b/doc/bugs/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment new file mode 100644 index 0000000000..d8e5aa97ee --- /dev/null +++ b/doc/bugs/annex_get_-J_16_via_ssh_stalls_/comment_26_a3d803f25795365c9651d2ec023d9145._comment @@ -0,0 +1,25 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 26""" + date="2018-11-05T21:32:20Z" + content=""" +tryLockExclusive is returning Nothing before the hang, when runTransfer +tries to lock the transfer log file. So runTransfer returns without +running the transfer action. + +Aha! ReadContent tries to run a transfer, and it calls +sinkfile with sender in the transfer action. +Never run, and so DATA never gets sent and indeed git-annex-shell is +waiting for the next command. + +Using alwaysRunTransfer would solve this; that's what Command.SendKey does. +And it would let concurrent downloads from a annex.pidlock remote work. +However, I'm not entirely happy with that, because as this shows any bug in +there that prevents the transfer action being run will lead to a protocol +stall. Seems it ought to detect when the transfer action didn't run, and +error out, somehow. + +Note that StoreContent also runs a transfer, but that does not involve +running a callback. So, might be ok. But, it may not consume the DATA +from the sender, so I need to look at it too. +"""]]