From a5fe62bed023eb06934256b470d7fd4d50a18a1f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 29 Mar 2018 14:10:10 -0400 Subject: [PATCH] hmm --- .../comment_5_786cc686ac7049c19d572329641bbb6d._comment | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/doc/bugs/Allow_automatic_retry_git_annex_get/comment_5_786cc686ac7049c19d572329641bbb6d._comment b/doc/bugs/Allow_automatic_retry_git_annex_get/comment_5_786cc686ac7049c19d572329641bbb6d._comment index 0d351aef20..dfb25f9227 100644 --- a/doc/bugs/Allow_automatic_retry_git_annex_get/comment_5_786cc686ac7049c19d572329641bbb6d._comment +++ b/doc/bugs/Allow_automatic_retry_git_annex_get/comment_5_786cc686ac7049c19d572329641bbb6d._comment @@ -19,4 +19,12 @@ be disabled for those. Hmm, a password prompt for eg ssh can also "stall" a transfer for a long time. Perhaps the thing to do is wait until the meter gets updated once, and only then start the stall detector. + +But what would the stall detector do when it does detect a stalled +transfer? It should perhaps cancel the transfer action, but I don't know +how to do that; the transfer action may have eg run a process, which would +need to be canceled, or it may have a network connection open. Simply +killing the transfer thread won't stop a process that it started. +And when an external special remote is performing the transfer, there's +nothing in that protocol to cancel a transfer. """]]