Hi, Rod.

RS> PE> Now what you see here is that the compressed sizes are different!!!
RS> PE> If it was a disk read error (or disk cache read error), it would have
RS> PE> created a different CRC, because the data would be different.

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

RS> Cant be that, doesnt explain the SAME CRC in the two files.
RS> THAT indicates that whatever is doing the CRC sees all the
RS> data fine, but it doesnt all get into the file created.

The 2 files were the *same* file. As I read the description the change
from $00 to $20 was a completely separate problem, which nevertheless
managed to confuse the situation.

RS> Let alone produce the result where using the dud file gets
RS> a complaint about the CRC coz the file has some missing bytes.

I don't think that's what happened. That's not how I read it.

RS> FM> In my example, the exact same file zipped using the
RS> FM> exact same program on my machine here cf the one at work,
RS> FM> gave different file sizes (it usually does in fact).

RS> Sure, different say ram available could well produce that
RS> result, BUT that is very unlikely to produce the SAME CRC.

From the same data it will, and that's what I think was happening. The
one byte change was a different problem.

Regards, fIM.

 * * Never let an inanimate object defeat you...
@EOT:

---