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

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

This is the corrupt one...

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

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

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



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

---