full upload happening even though only a timestamp has changed

[Tom Goulet]

> > As you can see, the second use of Rsync wrote 729805852 more bytes than
> > the first.
> The first time it didn't update the iso file.

I realise that... My problem is that it shouldn't have updated the file
the second time, since the remote file was identical to the local file.

> Normally rsync uses file size and mtime to decide whether to
> skip a file.  Generating checksums is expensive so that is
> not done unless updating the file.  If you use -c it will
> generate a file checksum on each end to decide whether to
> skip instead of comparing mtime.

Okay, I got all that.  So if the modification time is different, Rsync
should get a checksum, right?  And if the checksum is the same, Rsync
should not upload, right?  But in this case, Rsync is uploading even
though the checksum should be is the same.

> There is a known problem with files of this size where block
> checksums fail on the first pass.  When that happens there is
> a message that would look something like "redoing
> filename(1524)" in stdout.  It is possible you are
> encountering this problem and -P is hiding it.  Try
> redirecting stdout, don't use -P and perhaps add an extra
> -v.

I don't remember seeing that error message.  I tried your suggestion
using this command:
rsync -rtlvvessh /extra/library teep:/extra/tomg

The standard output will be available here (warning: it's 3.1MiB):
http://web.em.ca/~tomg/tmp/rsync_debug.0

The string "redoing" is not in the file of the standard output:
tomg at nova:~/mylibrary$ grep redoing rsync_debug.0
tomg at nova:~/mylibrary$

I had run the touch command on the Knoppix ISO file like I did in the
original post in this thread.  Rsync is definitely uploading the Knoppix
ISO again:
-rw-------    1 tomg     users    146636800 Apr 21 19:20 .KNOPPIX_V3.2-2003-04-18-EN.iso.FFb9TM
-rw-r--r--    1 tomg     users    729716736 Apr 21 18:33 KNOPPIX_V3.2-2003-04-18-EN.iso

So, are you convinced I have found a bug yet?

-- 
Tom Goulet, tomg at em.ca, D8BAD3BC, http://web.em.ca/~tomg/contact.html
 
I usually read no mail which is unsolicited and bulk, is not exclusively in
plain text, has advertising footers, is top-posted, or has bad line wrap.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20030422/5ec5d2cc/attachment.bin