Small bug in zip handling

[Tree]

For uncompressed zip files (in my case this was a jar archive made in Java), there is a small bug in the in zip.c at line 345

    finfo->uncompressed_position = newpos;

should read:

    finfo->uncompressed_position = newpos - entry->offset;

Without this fix, if you seek to the end of the current file, a tell returns the offset into the zip and not the 'file'.


On a related issue, when using a jar created using the default mechanism in Java, zip_parse_local returns a failure because the local header data for crc, compressed_size and uncompressed_size are all zero. I guess Sun don't bother adding this info by default. The BAIL_IF_MACRO macros checking these parameters against the respective values from the zip index can be commented out and the file loads the data fine. It is probably true that unless someone adds the CRCs lmanually (like we ended up doing), any Jar creates by the standard Java classes won't open under PhysFS. These files open in every other zip loader we have tried out so I guess they don't care about this data either.

My suggestion would be to remove the three offending BAIL tests at lines 775, 777 & 779, in zip.c, as any corruption is likely to be spotted by the other error checks. And this data isn't used by PhysFS anyway.

That's it,

Tree
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20030227/bd509b75/attachment.htm>