Bad MD5SUM and incorrect size of final ISO

[Mithras <mithras@dhp.com>]

Hello,

At first I suspected my problem was identical to Ricardo Marques', until I
recognized that my file's length has not been consistently 658929664.

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.

As I've been following the kit instructions, I've encountered a series of
problems; they may all be relevant but I'll begin with the most recent.

Each time I run rsync, it ends with a 'File changed during transfer?'
error, and mf5sum returns a bad checksum.  The following is not the
latest, but is typical:

binary-i386-1.iso
658927616 (99%)
ERROR: file corruption in binary-i386-1.iso. File changed during transfer?

(It always ends at 99%.)

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

(A more recent attempt had a size of 661762703.  I don't know what to
make of that.)

administrator@DEFCON1 /mnt/d/share/pseudo-image
$ md5sum -b binary-i386-1.iso
7f52ece72f136970d4a372964aae3c93 *binary-i386-1.iso

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.

I've been using aurolinux.mit.edu::debian-cd/ for rsync.

Because it could be relevant to this problem, and I'd planned to bring it
up anyhow, I'll back up now to describe an earlier problem I had.  When I
ran make-pseudo-image, I discovered that all of the transfers were
failing.  When I checked pseudo-image.log, I discovered that every get
command had resulted in 'Illegal PORT Command'.

When I tried to duplicate the commands from the script through my
interactive shell, I discovered that while I could connect to ftp sites
through ncftp2, and cd to known directories, ls and get always failed.  I
had the same problem with NT ftp.  I was mystified that I could visit ftp
sites through my Opera browser, and get 'Illegal PORT Command' whenever I
tried to do the same things at a command line.

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,
though I couldn't get 'set ftp pasv' or 'set passive on' to work for
this.  Interactive ncftp (not ncftp2) could actually get directory
listings, but it always failed with a 'need screen width greater than 21',
despite bash exporting COLUMNS=120.

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.

    (
      i=1

      # Generate a list of Wget commands
      # (modified to use ncftpget)

      while read ThisFileName
      do
	echo 'while [ ! -e '"$GetNextFile.$i"' ] ; do sleep 1 ; done ; rm
-f '"$GetNextFile.$i" >> "$Commands"
	echo 'ncftpget '"$2"''"$ThisFileName"' >> '"$LoggingFile"' 2>&1'
>> "$Commands"
	echo 'mv '"${ThisFileName##*/}"' '"$DownlFile.$i" >> "$Commands"
	echo 'echo $? > '"$FileReadyFile.$i" >> "$Commands"

	IncIWrap
      done
    ) < "$TodoFile"

I had hoped that once I'd started to build a pseudo-image (using files
from ftp://ftp.digex.net/debian/), my worries would be over.  But, ha ha
ha ha, rsync wouldn't cooperate, as I've already described.

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
with rsync, I assume it's maybe valuable for the cd-kit folks to know
about a problem that may reoccur on small company lans using lots of NT
mixed with redhat.  Anyhow.

I'm going to start from scratch, again, taking more copious notes .. if in
the meantime someone could suggest what I ought to be doing differently,
awesome.

(I've just lost all patience with Mandrake; it's time to try something
new.)

ben taylor

mithras@dhp.com / http://www.dhp.com/~mithras
716-586-0020 work, 716-256-2484 home, 716-233-3159 cell
174 Henrietta St. #2 / Rochester, NY 14620