1 files changed, 29 insertions, 0 deletions
diff --git a/doc/bugs/__34__byte-progress__34___could_jump_down_upon_initiating_re-download_--_report_actual_one_first__63__/comment_1_ee95564fafba601246df3de57500eb1c._comment b/doc/bugs/__34__byte-progress__34___could_jump_down_upon_initiating_re-download_--_report_actual_one_first__63__/comment_1_ee95564fafba601246df3de57500eb1c._comment
new file mode 100644
index 000000000..7f87e22b4
--- /dev/null
+++ b/doc/bugs/__34__byte-progress__34___could_jump_down_upon_initiating_re-download_--_report_actual_one_first__63__/comment_1_ee95564fafba601246df3de57500eb1c._comment
@@ -0,0 +1,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.
+"""]]