git-annex/Messages
Joey Hess 51c696679f
avoid using temp file size when deciding whether to retry failed transfer
When stall detection is enabled, and a transfer is in progress,
it would display a doubled message:

(transfer already in progress, or unable to take transfer lock) (transfer already in progress, or unable to take transfer lock)

That happened because the forward retry decider had a start size of 0,
and an end size of whatever amount of the object the other process had
downloaded. So it incorrectly thought that the transferrer process had
made progress, when it had in fact immediately given up with that
message.

Instead, use the reported value from the progress meter. If a remote
does not report progress, this will mean it doesn't forward retry, in a
situation where it used to. But most remotes do report progress, and any
remote that does not can be fixed to, by using watchFileSize when
downloading. Also, some remotes might preallocate the temp file (eg
bittorrent), so relying on statting its size at this level to get
progress is dubious.

The same change was made to Annex/Transfer.hs, although only
Annex/TransferrerPool.hs needed to be changed to avoid the duplicate
message.

(An alternate fix would have been to start the retry decider with the
size of the object file before downloading begins, rather than 0.)

Sponsored-by: Brett Eisenberg on Patreon
2021-06-25 12:04:23 -04:00
..
Concurrent.hs generalize to allow running in Assistant monad 2020-12-04 13:07:30 -04:00
Internal.hs clear progress bar before displaying messages 2021-06-15 20:51:40 -04:00
JSON.hs use TotalSize more extensively 2020-12-11 12:10:43 -04:00
Progress.hs display scanning message whenever reconcileStaged has enough files to chew on 2021-06-08 12:48:30 -04:00
Serialized.hs avoid using temp file size when deciding whether to retry failed transfer 2021-06-25 12:04:23 -04:00