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

FM> I don't know which ZIP you use (I use PIP 2.04g) but I have seen this.
FM> It depends what zip finds in the way of operating system, hardware, etc.
FM> eg if it finds a more competent processor it will use the appropriate
FM> instructions. In your case it's probably found a different amount of
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.

FM> The 2 files were the *same* file.

The same INPUT file, sure, clearly not the same OUTPUT file tho,
the length was different. So the CRC should be different too.

FM> As I read the description the change from $00 to $20 was a completely
FM> separate problem, which nevertheless managed to confuse the situation.

What was being discussed is if repeated rezipping of the SAME file
can produce DIFFERENT zip files, different lengths, but with the
SAME CRC. Its quite easy to see how repeated rezipping can produce
a differently compressed file, most obviously with a different set of
dictionary terms, but that WONT produce two files with the SAME CRC.

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

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

Thats what he said quite specifically. I did truncate
that quote back a long way from the original full text.

FM> In my example, the exact same file zipped using the
FM> exact same program on my machine here cf the one at work,
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.

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

Nope.
@EOT:

---