Bug 10450 - --info=progress2 increase %
--info=progress2 increase %
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.1.0
x86 Linux
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-15 17:32 UTC by Vania Toperich
Modified: 2014-02-24 18:04 UTC (History)
0 users

See Also:


Attachments
suggested patch (1.16 KB, patch)
2014-02-16 04:18 UTC, Anish Shankar
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vania Toperich 2014-02-15 17:32:11 UTC
--info=progress2 will not show increase of percentage done in real time as current throughput will. Percentage get's updated only after file has been transferred to destination. If you have 4 files you will get only 4 updates (jumps) of bandwidth %
Comment 1 Anish Shankar 2014-02-16 04:18:39 UTC
Created attachment 9689 [details]
suggested patch

I actually posted about the same a while back on the list, but was't sure if it was expected behaviour (I would think not), or a bug. I made a patch which appears to fix this issue for most of my use cases and have been using this for a while now. From what I've seen this should fix bug 10451 as well.
Comment 2 Anish Shankar 2014-02-16 04:22:04 UTC
(In reply to comment #0)
>Percentage get's updated only after file has been transferred to destination.
From what I noticed as well as looking the code, I think the percentage get's updated *before* the file even gets transferred , hence leading rsync to think that a huge file has been transferred instantaneously showing very huge unrealistic bandwidths. There after no more bytes transferred changes till the next file, causing speed to decay down again.
Comment 3 Vania Toperich 2014-02-16 08:46:21 UTC
Thanks.. I will try it out.

(In reply to comment #1)
> Created attachment 9689 [details]
> suggested patch
> 
> I actually posted about the same a while back on the list, but was't sure if it
> was expected behaviour (I would think not), or a bug. I made a patch which
> appears to fix this issue for most of my use cases and have been using this for
> a while now. From what I've seen this should fix bug 10451 as well.
Comment 4 Vania Toperich 2014-02-16 09:34:13 UTC
Yes it works perfectly. Thanks a lot.. Also speed is correct as well (it settles to correct value)

Have a nice day

(In reply to comment #3)
> Thanks.. I will try it out.
> 
> (In reply to comment #1)
> > Created attachment 9689 [details] [details]
> > suggested patch
> > 
> > I actually posted about the same a while back on the list, but was't sure if it
> > was expected behaviour (I would think not), or a bug. I made a patch which
> > appears to fix this issue for most of my use cases and have been using this for
> > a while now. From what I've seen this should fix bug 10451 as well.
Comment 5 Wayne Davison 2014-02-24 18:04:43 UTC
Thanks for the patch!  I think this makes the output much nicer.  I have applied it in the git repo for the next release.