aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2016-10-26 16:48:35 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2016-10-26 16:48:35 -0400
commit595bf3b5ef1a568300bf65030d61ca36d4c35ec9 (patch)
treeafbc617a00b9ec95327dc75f19b9ed05b3765ab2
parente356796fc7ee493ff6b6a7e9cbcbc2971ab23729 (diff)
devblog
-rw-r--r--doc/devblog/day_423__ssh_fun.mdwn19
1 files changed, 19 insertions, 0 deletions
diff --git a/doc/devblog/day_423__ssh_fun.mdwn b/doc/devblog/day_423__ssh_fun.mdwn
new file mode 100644
index 000000000..1fe12bc36
--- /dev/null
+++ b/doc/devblog/day_423__ssh_fun.mdwn
@@ -0,0 +1,19 @@
+Made a significant change today: Enabled automatic retrying of transfers
+that fail. It's only done if the previous try managed to advance the
+progress by some amount. The assistant has already had that retrying for
+many years, but now it will also be done when using git-annex at the
+command line.
+
+One good reason for a transfer to fail and need a retry is when the network
+connection stalls. You'd think that TCP keepalives would detect this kind
+of thing and kill the connection but I've had enough complaints, that I
+suppose that doesn't always work or gets disabled. Ssh has a
+ServerAliveInterval that detects such stalls nicely for the kind of batch
+transfers git-annex uses ssh for, but it's not enabled by default. So I
+found a way to make git-annex enable it, while still letting ~/.ssh/config
+settings override that.
+
+Also got back to analizing an old bug report about proliferating
+".nfs*.lock" files when using git-annex on nfs; this was caused by the
+wacky NFS behavior of renaming deleted files, and I found a change to the
+ssh connection caching cleanup code that should avoid the problem.