Red Hat Bugzilla – Bug 127613
progress output in wrong order
Last modified: 2015-01-04 17:07:44 EST
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.
Created attachment 107453 [details] fix.
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)
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.