Re: correct-i386-2 proved useless.
On Fri, 22 Sep 2000, Luca Santarelli wrote:
> >but your "Wrong size" seems to be truthful.)
>
> The strange thing is that my file has the _same exact_ size of the image
> present on ftp.debian.org: 672.960.512 bytes. This I forgot to tell in my
> previous email, excuse me.
These are the one-and-only correct sizes:
658929664 Aug 14 09:00 binary-i386-1.iso
670251008 Aug 14 09:01 binary-i386-1_NONUS.iso
672960512 Aug 22 20:15 binary-i386-2.iso
526833664 Aug 14 09:04 binary-i386-3.iso
So your 672.960.512 does indeed seem to be correct.
> >You could try correct-i386-2 a second time; it should then say "already
> >corrected[...]" which would mean the offending bit really was corrected
> >the first time.
>
> I did this too, and excuse me for having forgot to report it here in the
> previous email. (usually I am a good beta tester, though ;-)) As you
> suspected, it told me: "File not corrected: [cut] maybe already corrected?
> Error is: 0"
Okay. And you surely did "md5sum -b", didn't you? (the -b is terribly
important)
> >Before starting rsync (with the pseudo-image/wrongly-rsynced-image
> >already present!), you should have at least 650 MB free disk space, since
> >rsync will build a second, new copy of the image, while the old copy is
> >still present.
>
> I have almost 1GB free. I noted a problem, though. If I start a rsync
> session but I stop it after a while, then, when I start again, it _doesn't_
> resume but starts from beginning making a new file w/ the same name and a
Correct, that's the way it's supposed to work. (At least at this moment; I'd
love to see some changes in the rsync protocol to enable resuming.)
> >Try rsyncing again, but now with a larger block-size, like 20000 or even
> >123456. This solves most problems in most cases.
>
> I tried w/ 12345, then left the computer working. When I was back, there
> was a I/O error... well. Why? I don't know. :-)
Does happen sometimes. rsync seems to be quite sensitive to network problems.
> I tried it again changing server (I was on ftp.debian.org) and went to the
> italian rsync mirror. This time I tought: if blocksize is the size of the
> blocks being "checksum-ed", if I put a _smaller_ value, the checksum will
> be "better" and maybe will help things. This was due to the fact that I
> already had a size in mind: 4096, which is both the missing file size (but
> the image on the site and pseudo-image I have share the same filesize) and
> the size of my clusters (FAT32).
Good thinking, but not quite accurate. The point is that the checksums are
only 16-bit, so there are 65536 checksums possible. With 4096-byte blocks,
there are about 160000 blocks in a CD image. This means that at least 100000
blocks have a duplicated checksum, but different data! Now if I understand
rsync correctly, the server will see this, and will disregard every checksum
that occurs more than once -- and it'll send data for these blocks literally.
That's why large blocks work more correctly; and a second run with different
block-size should undo all (most) aliasing effects that might have occured.
> Note: I even defragmented and run scandisk afraid of ONE broken cluster on
> the HD or something like that, but it didn't bring any good news.
(I'd call it bad news, since broken clusters usually mean big trouble ;-)
Regards,
Anne Bezemer
Reply to: