Count of files to be transferred

Ryan Joseph thealchemistguild at
Fri Apr 30 22:04:54 MDT 2010

On May 1, 2010, at 4:29 AM, Matt McCutchen wrote:

> On Fri, 2010-04-30 at 14:21 +0700, Ryan Joseph wrote:
>> On Apr 30, 2010, at 12:54 PM, Matt McCutchen wrote:
>>> Rsync determines which of the files in the file list need a data
>>> transfer as it goes, so the only way to get the count in advance is to
>>> do a separate dry run.  Then you could take the "Number of files
>>> transferred" from --stats output.
>> What do you mean "dry run" and wouldn't that take as much time as the
>> real backup thus effectively doubling the time? If so that's probably
>> not a good option.
> Rsync has a --dry-run option to run without actually making the changes
> to the destination.  The source and destination are scanned as normal,
> but transmission of the contents of files is skipped.  See the man page
> for more information.

The man page I was looking at (hosted by Apple) didn't show this option but it appears to be in the software and working. This is the option I was looking for but the performance impact is going to be difficult to work around. It's much faster than the actual transfer but still requires a significant amount of time to run. The solution may be to process the dry run in the background and hopefully by the time the user performs a backup the file count will be returned and available, but that seems like a waste of processor just to get a progress bar. If so many users didn't email me requesting this feature I would assume just forget about it. ;)

Thanks though, I think this is the proper solution if I can implement it properly.

>>> Alternatively, you could base the progress bar on the total number of
>>> entries in the file list.  The --progress option does this, but it won't
>>> be accurate if incremental recursion is enabled.
>> I tried the --progress option but it only seemed to show the progress
>> for each file which really isn't helpful for my case. 
> See the "to-check" values at the end of each progress line, for example:
> $ rsync -r --progress src2/ dest2/
> sending incremental file list
> created directory dest2
> ./
> filea
>           0 100%    0.00kB/s    0:00:00 (xfer#1, to-check=1/3)
> fileb
>           0 100%    0.00kB/s    0:00:00 (xfer#2, to-check=0/3)
> sent 126 bytes  received 53 bytes  358.00 bytes/sec
> total size is 0  speedup is 0.00

I see now. I think that ratio is based off of the total amount of files and not the files transferred so it won't help any.


More information about the rsync mailing list