Andrew,
Thanks very much for the response!
I am embarrassed -- I realize why rsync was copying the entire file --
my mistake -- I started it from the wrong directory and it was creating
the file from scratch. Anyway that's the good news (sort of).
The bad news is that I'm back to the situation I was in before, when I
start rsync (under various circumstances), after a short period it puts
out a message "unexpected EOF in read-timeout" and then, after another
short period, quits, with no change to the file.
This also happens if I restart rsync on the new iso that rsync was
creating from scratch.
I followed your suggestion (comparing the two files) -- I split the
files into 10 MB files and then compared them with diff. The first 10
MB is identical. diff tells me there are differences in the next two
sections, but doesn't show them to me (so far). (The files (sections)
are the same size.
I've read some of your thesis -- it's quite interesting.
I'm punchy right now, and I need to walk away and leave the computer for
a while. Then I need to concentrate on getting my taxes done before
April 16. So, I'll let this sit on the back burner for a little while
-- maybe when I come back to it I'll make some progress.
I was going to upgrade rsync to a later version (I'm using 2.3.2 with
protocol version 21 -- carroll is using protocol version 24), but I'm a
Linux newbie and I haven't found a precompiled rpm for Mandrake 7.0.
So, thanks very much to everyone who offered help! I'll be back!
Randy Kramer
Andrew Tridgell wrote:
>
> Here are some possible explanations:
>
> 1) you used --partial on an earlier attempt and interrupted the
> transfer. That would leave you with a partial and potentially much
> smaller image locally, which would mean a subsequent transfer would
> send most of the file
>
> 2) the corruption is spread throughout the file, for example crlf
> conversion. If the corruption occurs more often than the block size
> that rsync chooses (assuming you don't override the choice) then
> rsync will end up sending the whole file.
>
> I suspect that (2) is the problem. To check this try dumping a piece
> of the two files (perhaps with "od") and looking at what differs
> between them. If it is a regular difference then you could use a
> program to "fix" that difference as best you can, then use rsync to
> fix up any still broken blocks.
>
> If you are interested in approaching this problem from an academic
> point of view then you might like to look in the subsection "Text
> transformation" in chapter 4 of my thesis. That section looks at how
> to efficiently handle this type of corruption. The current versions of
> rsync don't use the method in that section.
>
> Cheers, Tridge
