summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-05-25 14:30:18 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-05-25 14:30:18 -0400
commit5c874fd5f5f6dcdf2889d3db7d4429553859ccd6 (patch)
tree643e3a575fa83c9eae4de36a882b9eeb5f6c912b
parent0c430fc08ea6a6b95bb975ed1eaf2c1012a6d67a (diff)
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.
-rw-r--r--CHANGELOG2
-rw-r--r--Utility/Metered.hs23
-rw-r--r--doc/bugs/__34__byte-progress__34___could_jump_down_upon_initiating_re-download_--_report_actual_one_first__63__/comment_1_ee95564fafba601246df3de57500eb1c._comment29
3 files changed, 45 insertions, 9 deletions
diff --git a/CHANGELOG b/CHANGELOG
index 0d65af1c9..dd408a0b5 100644
--- a/CHANGELOG
+++ b/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
diff --git a/Utility/Metered.hs b/Utility/Metered.hs
index 626aa2ca1..a5dda5413 100644
--- a/Utility/Metered.hs
+++ b/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
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.
+"""]]