Hi,
I've made some progress in getting rsync to work on the .iso I'm
downloading, but now I've got another problem -- AFAICT, rsync is
re-downloading the entire file!
To recap briefly, I had downloaded an iso (mandrakefreq) using NCFTP,
but the md5sum was bad. I am hoping to use rsync to correct it.
After some false starts and overcoming other problems (which I describe
below, FWIW), I invoked rsync with the following command line:
rsync -c -vv --progress --partial \
carroll.cac.psu.edu::mandrake-iso/mandrakefreq-i586-20010316.iso \
mandrakefreq-i586-20010316.iso
(While the PWD is the directory containing the iso with the bad md5sum.)
rsync is now giving me a byte count and a % complete (e.g., "18846488
(2%)") and acting like it's downloading the entire file, in other words,
not just downloading portions of the file. (My suspicicion that it's
downloading the entire file is based on the speed of transfer -- I'm
using a 33.6 kbps modem and usually get 9 to 11 megabytes per hour (or
less) as a transfer rate. I've had rsync running for about two hours
and, as you can see, it's downloaded almost 19 MB.) (As I sent this
email, the byte count was up to about 24 MB after about 2 1/2 hours.)
I'm using rsync 2.3.2 protocol version 21 (Mandrake 7.0). The rsync
server at carroll.cac.psu.edu uses protocol version 24.
What am I doing wrong?
Theories about my current problem:
1. rsync can't repair an iso file except by retransmitting the entire
file -- unlikely -- somebody would have told me this by now, and some of
my earlier trials produced results like:
wrote 105 bytes read 85 bytes 20.00 bytes/sec
total size is 684400640 speedup is 3602108.63
(But the file (and md5sum) did not change.)
2. rsync is transmitting only portions of the iso file, but the overhead
involved in doing the checksums on both ends makes the transfer time
about the same as a total transfer at the speed of my 33.6 kbps modem --
I would be surprised -- that would be quite a coincidence.
3. There is something wrong in my command line -- this would not
surprise me.
4. In the course of transferring the iso with the bad md5sum to a
CD-Rom, then reading the CD on another computer (under Windows), then
back to this computer using samba, it has become more corrupted, and
retransmitting every "packet" is required. (Hmm, I can test this by
running md5 on the transferred iso again, and compare it to the original
bad iso.) -- Nope -- disproven -- the md5sum is the same (bad) md5sum
from before the iso's oddysey.
5. The md5sum is not bad. -- This is sort of obsolete, and pretty much
of a non-sequitur in this discussion. -- Not too likely -- this was an
earlier theory, disproven now because rsync seems to be retransmitting
the entire file. (And the trial after touching the local file to ensure
a date mismatch but getting no change in the file contributed useful
information at the time, but again, is irrelevant at this point.)
6. The problem is due to the protocol mismatch. -- Not too likely --
this condition prevailed throughout the trials, even when I got the
"wrote 105 bytes read 85 bytes 20.00 bytes/sec" results.
7. Other??
Thanks for any help anyone can offer!
Randy Kramer
PS: Some other information (problems I've overcome, maybe):
If you noticed some of my earlier posts, I suspected that a different
problem (I got the message "unexpected EOF in read_timeout" and no
change to the local copy of the iso file) might be because the local
copy of the iso was in a FAT32 partition. I've now converted to an ext2
partition, but after making the conversion I still had the same
problem. I was using -vvv as one of my options. I tried deleting one
of the v's, and am now getting the behavior described above.
So:
-there seems to be a problem using -vvv as an option
-I don't know whether the FAT32 partition was a problem or not. I
suspect not, and when I convert the partition back again, I'll try it
again.
