Bug 127613 – progress output in wrong order

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 127613 - progress output in wrong order

Summary:	progress output in wrong order

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	rsync (Show other bugs)
Sub Component:
Version:	3
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Jay Fenlason
QA Contact:	Mike McLean
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2004-07-10 18:49 EDT by Dave Jones
Modified:	2015-01-04 17:07 EST (History)
CC List:	3 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2004-11-29 13:11:57 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
fix. (546 bytes, patch) 2004-11-25 02:02 EST, Dave Jones	no flags	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Dave Jones 2004-07-10 18:49:14 EDT

Description of problem:
With --progress, rsync outputs text like so...

650534912 100%    1.08MB/s    0:09:33  (4, 89.7% of 29)

which looks odd, (89.7%, 4 of 29) would seem to make more sense.

Comment 1 Dave Jones 2004-11-25 02:02:33 EST

Created attachment 107453 [details]
fix.

Comment 2 Dave Jones 2004-11-25 02:04:45 EST

attached patch seems to work for me, though it might be highlighting another bug.

Look at this output..

zlib/zutil.o
        7872 100%   19.66kB/s    0:00:00  (100.0%, 249 of 260)

sent 1258665 bytes  received 5000 bytes  2527330.00 bytes/sec
total size is 3874565  speedup is 3.


Shouldn't that last one be 260 of 260 ?  It seems it isn't
counting directories properly.  (This was an rsync of the rsync src dir,
which has 249 files and 11 dirs)

Comment 3 Jay Fenlason 2004-11-29 13:11:57 EST

From the upstream maintainer: 
 
The bug reporter is misreading the output.  As stated in the manpage 
(with *highlighting* added by me): 
 
    After a file is complete, the data looks like this: 
 
         1238099 100%  146.38kB/s    0:00:08  (5, 57.1% of 396) 
 
    This tells you the final file size, that it's 100% complete, the 
    final transfer rate for the file, the amount of elapsed time it 
took 
    to transfer the file, and the addition of a total-transfer 
summary 
    in parentheses.  These additional numbers tell you *how many 
files 
    have been updated*, and what percent of the total number of 
files 
    has been scanned. 
 
The bug reporter is misinterpreting the first number -- the output 
is 
correct as is.  Note also that rsync has no idea how many files it 
will 
transfer before starting to transfer files (and it would slow it 
down to 
do that extra scan beforehand, so it will never be done). 
 
Feel free to discuss any suggestions for changing the output on the 
mailing list, but just swapping the numbers (as suggested in bug 
127613) 
would result in a bogus display of information, and will not be 
considered.

Note You need to log in before you can comment on or make changes to this bug.