rsync compression (-z) and timestamp

[Matt McCutchen]

On Tue, 2009-02-03 at 14:46 +0100, David de Lama wrote:
> >The first command is transferring the file and the second is not,
> >because the file has already been transferred.  That's why the first
> >command is taking longer.  What did you expect to see?
> >
> >
> >-- 
> >Matt
> 
> 
> Thanks for your patience, Matt.
> But when I change the user rights on this file with chmod and than run rsync, it takes 2sec without -c, and 35sec with -c.
> Therefore I am confused! Or didn't I understand it yet!

Sorry, please ignore my previous message; I got confused about what you
were doing.  In complex threads such as this, it would help me if you
would paste your entire session of commands and output and then annotate
it as necessary rather than picking out the parts you consider most
relevant.

Rsync uses a "quick check" criterion to decide whether a regular file's
content needs to be transferred.  By default, the criterion is a
difference in size or modification time.  The -c option changes it to a
difference in checksum, as determined by reading both files in full.
After rsync has either transferred the content or decided that no
transfer is necessary, it sets the destination file's attributes
according to your options.

Each time you tested with the -c option, rsync read both files in full
to compute their checksums (taking about 40 sec), skipped the transfer
because the checksums were the same, and made any necessary attribute
updates on the destination file.  It didn't matter whether you touched
or chmodded the source file.

When you tested without -c, rsync just looked at the size and
modification time of both files (taking essentially no time).  Touching
the source file caused this check to fail, so rsync retransferred the
file (about 80 sec).  Chmodding the source file had no effect on the
check, so rsync skipped the transfer.

Does it make sense now?  (See also the description of -c in the man
page.)

-- 
Matt