Improve progress display when watching file size, in cases where a transfer does not resume.

This commit was supported by the NSF-funded DataLad project.

CHANGELOG

@@ -2,6 +2,8 @@ git-annex (6.20170520) UNRELEASED; urgency=medium
 
   * initremote, enableremote: Support gpg subkeys suffixed with an
     exclamation mark, which forces gpg to use a specific subkey.
+  * Improve progress display when watching file size, in cases where
+    a transfer does not resume.
 
  -- Joey Hess <id@joeyh.name>  Wed, 24 May 2017 14:03:40 -0400
 

Utility/Metered.hs

@@ -171,22 +171,27 @@ defaultChunkSize = 32 * k - chunkOverhead
 	k = 1024
 	chunkOverhead = 2 * sizeOf (1 :: Int) -- GHC specific
 
-{- Runs an action, watching a file as it grows and updating the meter. -}
+{- Runs an action, watching a file as it grows and updating the meter.
+ -
+ - The file may already exist, and the action could throw the original file
+ - away and start over. To avoid reporting the original file size followed
+ - by a smaller size in that case, wait until the file starts growing
+ - before updating the meter for the first time.
+ -}
 watchFileSize :: (MonadIO m, MonadMask m) => FilePath -> MeterUpdate -> m a -> m a
 watchFileSize f p a = bracket 
-	(liftIO $ forkIO $ watcher zeroBytesProcessed)
+	(liftIO $ forkIO $ watcher =<< getsz)
 	(liftIO . void . tryIO . killThread)
 	(const a)
   where
 	watcher oldsz = do
-		v <- catchMaybeIO $ toBytesProcessed <$> getFileSize f
-		newsz <- case v of
-			Just sz | sz /= oldsz -> do
-				p sz
-				return sz
-			_ -> return oldsz
 		threadDelay 500000 -- 0.5 seconds
-		watcher newsz
+		sz <- getsz
+		when (sz > oldsz) $
+			p sz
+		watcher sz
+	getsz = catchDefaultIO zeroBytesProcessed $
+		toBytesProcessed <$> getFileSize f
 
 data OutputHandler = OutputHandler
 	{ quietMode :: Bool

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.
+"""]]