David Bolen wrote:

> The discovery phase will by default just check timestamps and sizes.
> You can adjust that with command line options, including the use of -c
> to include a full file checksum as part of the comparison, if for
> example, files might change without affecting timestamp or size.
> 
> Once rsync knows what it needs to transfer, then it works its way
> through the file list, and for each file it performs a transfer.  By
> default, that transfer is the rsync protocol - which involves the full
> process of dividing the file into chunks with both a strong and
> rolling checksum, and doing the computations to figure out what parts
> to send and so on.

This is where the docs were a bit confusing.  There was no clear
distinction of checksum types related to the -c option.  This implied
to me that w/o -c there would be no checksum at all, and what I thought
the behaviour would be was what I now understand it to be with -W.


> That's why the -W option is really the only logical thing to use with
> a single rsync and "local" (on-system or network share/mount) copies.
> Under such circumstances, the rsync protocol isn't going to help at
> all, and will probably slow things down and take more memory instead.
> With -W rsync becomes an intelligent copier (in terms of figuring out
> what changed), but that's about it.

Actually, the lack of -W isn't helping me at all.  The reason is that
even for the stuff I do over the network, 99% of it is compressed with
gzip or bzip2.  If the files change, the originals were changed and a
new compression is made, and usually most of the file is different.

It definitely helped for transferring ISO images where the whole image
would be changed if some files changed.  I set the chunk size to 2048
for that.  Why it defaults to 700 seems odd to me.

There is a feature I would like, and I notice that even with -c this
does not happen, but I think it could based on the way rsync works.
What I'd like to have is when a whole file is moved from one directory
to another, rsync would detect a new file with the same checksum as an
existing (potentially to be deleted) file, and copy, move, or link, as
appropriate.  In theory this should apply to anything anywhere in the
whole file tree being processed.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------

Reply via email to