[erlang-bugs] Bug in .ZIP file reader

[Aaron Miller]

The .ZIP data descriptor block, if present is stored after the file data in a .ZIP file, but prim_zip handles it as if it were -before- the file data. 
http://en.wikipedia.org/wiki/ZIP_(file_format)#File_headers
https://github.com/erlang/otp/blob/dev/erts/preloaded/src/prim_zip.erl#L183

A file in a .ZIP with a data descriptor block if compressed will simply fail to read (due to the first 12 bytes being chopped off), and if uncompressed will have their first 12 bytes chopped off and returned with the data descriptor block on the end. I haven't found any ZIP implementations that store uncompressed files with a data descriptor block, but I have created one in the test zip file I have attached. 

1> erl_prim_loader:get_file("test.ez/file.compressed").
error
2> erl_prim_loader:get_file("test.ez/file.uncompressed").
{ok,<<"Uncompressed text.\n">>,"test.ez/file.uncompressed"}
3> erl_prim_loader:get_file("test.ez/file.uncompressed.with.descriptor").
{ok,<<32,116,101,120,116,46,10,80,75,7,8,28,191,106,205,
 19,0,0,0,19,0,0,0>>,
 "test.ez/file.uncompressed.with.descriptor"}



It works for my purposes to just delete the descriptor handling as I've done here: https://github.com/couchbaselabs/otp/commit/126a990d75311a2da59b6c6e85d05e47edb39a5a#diff-8
But, this will still return data with junk on the end (16 bytes of it, actually, as the descriptor block is 16 bytes long, not 12.), in the case that an uncompressed file is stored with a descriptor block (which doesn't happen in any zip files I have lying around).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20110916/6a2ba693/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.ez
Type: application/octet-stream
Size: 533 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20110916/6a2ba693/attachment.obj>