2 bugs involving new stalldetection feature

diff --git a/doc/todo/ctrl_c_propagation_to_transferrer_process.mdwn b/doc/todo/ctrl_c_propagation_to_transferrer_process.mdwn
new file mode 100644 (file)
index 0000000..6cb74e5
--- /dev/null
+++ b/doc/todo/ctrl_c_propagation_to_transferrer_process.mdwn
@@ -0,0 +1,23 @@
+When annex.stalldetection is set, and git-annex transferrer is used,
+a ctrl-c does not propagate to the transferrer process.
+
+The result is that, the next time the process sends a message to its output
+handle (eg a progress update), it gets a SIGINT, and so an ugly message is
+output to the console, after the user was returned to the prompt.
+
+The SIGINT is not propagated because a child process group is used for
+git-annex transferrer, in order to let child processes of it be killed
+along with it when a stall is detected.
+
+Maybe what's needed is a SIGINT handler in the main git-annex that
+signals all the transferrer processes with SIGINT and waits on them
+exiting. Unsure if that can be implemented in haskell?
+
+Or, note that it would suffice to remove the child process group stuff,
+if we assume that all child processes started by git-annex transferrer are
+talking to a pipe, and will output something, eg a progress update,
+and so receive a SIGPIPE once the transferrer process has caught the
+SIGINT and exited.
+[[todo/stalldetection_does_not_work_for_rsync_and_gcrypt]] would be a
+prereq for this approach. But, might there be long-running child processes
+that are not on a pipe, and that need to be shutdown on a stall, too?

diff --git a/doc/todo/stalldetection_does_not_work_for_rsync_and_gcrypt.mdwn b/doc/todo/stalldetection_does_not_work_for_rsync_and_gcrypt.mdwn
new file mode 100644 (file)
index 0000000..56e6acf
--- /dev/null
+++ b/doc/todo/stalldetection_does_not_work_for_rsync_and_gcrypt.mdwn
@@ -0,0 +1,11 @@
+When annex.stalldetection is set, rsync and gcrypt
+special remotes do not display any progress. Also, the stall detection
+cannot detect stalls, because that needs progress information to do.
+
+These remotes have  `displayProgress = False`, and seem to be the only
+affected ones.
+
+It seems like it would be a good idea to make these remotes capture the
+output of the program they run, and convert it to a progress meter.
+
+(Also, these don't have progress output with -J either..)