When this happens, the transfer will be considered to have failed, so
settings like annex.retry will control what it does next.
- This is not enabled by default, because it can make git-annex use
- more resources. In order to cancel stalls, git-annex has to run
- transfers in separate processes (one per concurrent job). So it
- may need to open more connections to a remote than usual, or
- the communication with those processes may make it a bit slower.
-
The value specifies how much data git-annex should expect to see
flowing, minimum, when it's not stalled, over a given period of time.
The format is "$amount/$timeperiod".
stuck for a long time, you could use:
`git config remote.usbdrive.annex-stalldetection "1MB/1m"`
+ This is not enabled by default, because it can make git-annex use
+ more resources. To be able to cancel stalls, git-annex has to run
+ transfers in separate processes (one per concurrent job). So it
+ may need to open more connections to a remote than usual, or
+ the communication with those processes may make it a bit slower.
+
* `remote.<name>.annex-checkuuid`
This only affects remotes that have their url pointing to a directory on