aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/__34__byte-progress__34___could_jump_down_upon_initiating_re-download_--_report_actual_one_first__63__/comment_1_ee95564fafba601246df3de57500eb1c._comment
blob: 7f87e22b41246463a6e9f79cd2ccdf15072d5955 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2017-05-25T17:56:48Z"
 content="""
That looks like a git remote accessed perhaps by rsync, or perhaps locally?

I'd be surprised if a rsync transfer did this, because AFAIK all progress
updates come from rsync's own progress display, and that does not jump
backward.

Local file copies (when not using rsync), and some other types of remotes,
poll the size of the temp file to determine how much data has been
received, and so if the transfer doesn't resume, they will do this. **I've
made it avoid reporting the file size until the file size has changed once,
which avoids the problem in this case.**

Another way it could happen is when a transfer fails partway and git-annex
immediately retries and the retry fails to resume. In
this case, the progress would go to some percent for the first transfer,
and then could reset to a lower percent for the retry, and that
reflects what's really happening. Eg, 50% of it transferred and now
we've unfortunately started over at 0%.

I could make the reported progress always be monotonically increasing, but
then in that retry cases it would just seem to stall, perhaps for a long
period of time. Not sure that's better than a progress display that while
annoying, reflects what's really going on.
"""]]