full upload happening even though only a timestamp has changed
tomg at em.ca
Tue Apr 22 11:32:54 EST 2003
> > 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
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):
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
-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
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20030422/5ec5d2cc/attachment.bin
More information about the rsync