Re: Bad MD5SUM and incorrect size of final ISO
On Mon, 18 Sep 2000, Mithras wrote:
> I'm using the Pseudo Image Kit for Windows, on Windows NT 4.0, behind our
> company's firewall.
>
> Also, I have had cygwin 1.1.4 installed.
Hmm. Conflicting versions of cygwin _might_ prove problematic, but I think
you're the first to try ;-)
> binary-i386-1.iso
> 658927616 (99%)
> ERROR: file corruption in binary-i386-1.iso. File changed during transfer?
>
> (It always ends at 99%.)
Rsync never prints the 100% (could be considered a bug, but well..)
> Number of files: 1
> Number of files transferred: 1
> Total file size: 658929664 bytes
> Total transferred file size: 658929664 bytes
> Literal data: 636549120 bytes
> Matched data: 22380544 bytes
> File list size: 40
> Total bytes written: 475161
> Total bytes read: 636638681
>
> wrote 475161 bytes read 636638681 bytes 101233.63 bytes/sec
> total size is 658929664 speedup is 1.03
Oh oh, that's no good at all. Only 22 MB of your pseudo-image was used by
rsync... It's a good idea to try with another rsync mirrror and see what that
does.
> After I had seen this result and Ricardo's thread, I tried changing the
> size of the blocks, but the total bytes written was not one block, but
> several.
If you still have a faulty rsynced image, try rsyncing it again (with large
blocks) from some other mirror.
> In fact, I'm still mystified, but I found a way around it Sunday night. A
> coworker implied that our firewall may only permit passive connections,
Also try accessing the mirror by HTTP (or some other mirror that offers HTTP
access). You can then even use a proxy if you have to.
> So I changed the make-pseudo-script to use ncftpget in place of wget.
> wget failed for other, similar faults, but ncftpget, which I picked up
> from the www.ncftp.com site, could transfer files just fine.
You're perfectly sure it's "just fine"? Transferring from *UX to Windows
systems mostly defaults to ascii-mode transfers, and that's something we
definately don't want (and would explain the terribly small amount of matched
data)...
> I understand that rsync is meant to replace copies of non-matching blocks
> with the remote blocks, in principle correcting your local copy to match
> the remote copy in minimum time, so it shouldn't matter if there are some
> inconsistencies in my original, as long as it isn't, say, random
> noise. But even if my earlier problem has nothing to do with my failures
And it even wouldn't matter if you started with all random data -- rsync
should get it perfectly allright, maybe after 2 or 3 tries with different
(large) block-sizes. Isn't there "something" with your firewall which is
affecting the data "somehow"?
Regards,
Anne Bezemer
Reply to: