Rsync shouldn't display a meaningless speedup on a dry run

[foner-rsync at media.mit.edu]

    Date: Tue, 06 Nov 2007 23:18:08 -0500
    From: Matt McCutchen <matt at mattmccutchen.net>

    On Tue, 2007-11-06 at 22:22 -0500, foner-rsync at media.mit.edu wrote:
    > I worry about those trying to write things that parse rsync's output;
    > if -n changes the output format, such things will have to be tested on
    > live data.

    No, just run rsync's output through a sed script that adds the desired
    speedup to the last line.

That changes the test setup quite a lot with and without -n.

    > Is it possible (e.g., without ridiculous amounts of code-massaging) to
    > have -n output the speedup (or some more-reasonable estimate) anyway?
    > Sure, all kinds of differences haven't been computed, but...

    Rsync could estimate an upper bound on how much a real run might send by
    adding the size of the data that wasn't transferred (regular file data
    and abbreviated xattrs) to the amount the dry run sent, but I'm not sure
    the resulting value would be useful enough to make this worthwhile.

I could go either way.

    > Or maybe
    > just have it report a speedup of 1.00 instead?  Still misleading, but
    > it preserves the output format and is trivial to write (but still,
    > alas, confusing for the user, so this doesn't fill me with glee).

    That lie would be no improvement over the current one.

Then how about this:  If your patch winds up in rsync, it requires a
patch to the manpage entry for -n that says, essentially, "You can't
trust the actual information emitted when running with -n to match
what gets emitted if you haven't specified -n.  Therefore, if you're
writing things that parse rsync's output, you must ensure that your
script works with and without -n.  Here is an itemization of those
things that might be different in its output with and without -n:
  (a) With -n, the speedup line will be omitted.
  (b) ....?"
Etc.

At least that way, someone writing such a tool will be warned without
having to find out the hard way.

(I don't write such tools, but I've certainly seen some, and read some
chatter about them on this list.)