Hi, Paul.

PE> PE> Well, enough of the P.S.'s, I just got some mail scanned.  I got a CRC
PE> PE> error in one of my zip files.  This zip file was one that MY system
PE> PE> (3:711/934) packed up to go MY point (.9), ie there is no-one else to
PE> blame
PE> PE> other than my system.  I have put the disk cache back down to what it
PE> used
PE> PE> to be with Warp 3 (8 meg) in the hope that the problems (two data
PE> integrity
PE> PE> loss situations in just a few hours) are due to that and will go away.

PE> Well, I managed to reconstruct the original file, and I found out that all 
PE> lost was a 0x00 was converted into a 0x20.  With the correct input file (ie
PE> 0x00), I did the compression again, and the CRC came out to be the same as
PE> the corrupt archive stated, ie I am sure that I have the input file correct
PE> HOWEVER, the two archives were different sizes, specifically...

PE> This is the corrupt one...

PE> Archive:  0000fff7.th0
PE>  Length  Method   Size  Ratio   Date    Time   CRC-32     Name
("^" ==>
PE> case
PE>  ------  ------   ----  -----   ----    ----   ------     ----
PE> conversion)
PE>  338731  Defl:X  115964  66%  12-12-96  21:06  208def74  ^2afe7640.pkt
PE>  ------          ------  ---                              -------
PE>  338731          115964  66%                              1

PE> This is doing the zip again, after painfully reconstructing the original
PE> file...

PE> Archive:  jjj.zip
PE>  Length  Method   Size  Ratio   Date    Time   CRC-32     Name
("^" ==>
PE> case
PE>  ------  ------   ----  -----   ----    ----   ------     ----
PE> conversion)
PE>  338731  Defl:X  115960  66%  12-12-96  23:32  208def74  ^2afe7640.pkt
PE>  ------          ------  ---                              -------
PE>  338731          115960  66%                              1



PE> Now what you see here is that the compressed sizes are different!!!  If it
PE> was a disk read error (or disk cache read error), it would have created a
PE> different CRC, because the data would be different.  If it was a disk write
PE> error (or cache error), the SIZE would be the same.  The only way that this
PE> anomaly could have occurred is if zip was reading the data, and calculated
PE> the CRC of a particular byte, and then passed a DIFFERENT byte to the
PE> compression routines.  This could be a zip bug, but more likely, the stack
PE> has been clobbered or memory corrupted, by something else.  ie it is an OS/
PE> system fault.  Probably most likely to be some interrupt handler screwing
PE> around with the stack?  BFN.  Paul.

I don't know which ZIP you use (I use PIP 2.04g) but I have seen this.
It depends what zip finds in the way of operating system, hardware, etc.
eg if it finds a more competent processor it will use the appropriate
instructions. In your case it's probably found a different amount of
memory, enabling it to build a bigger table when it could.

In my example, the exact same file zipped using the exact same program
on my machine here cf the one at work, gave different file sizes (it
usually does in fact). I've never bothered to find the exact cause but
you could try playing with the "trouble shooting" options. (Run it with
no proms, press 4 for a list - if you're using pip.)

Regards, fIM.

 * * BETA testing is hazardous to your health.
@EOT:

---