search

99991 / ParallelZipFile

Quick hacky parallel ZipFile implementation
MIT License
3 stars 1 forks source link

Bug in Zip64 EOCD decoding. #1

Open eliphatfs opened 1 year ago

eliphatfs commented 1 year ago

If there are more than 65535 files but the directory offset is within Zip range, the offset is not required to be set to 0xffffffff.

To signal that the actual values are stored in ZIP64 extra fields, they are set to 0xFFFF or 0xFFFFFFFF in the corresponding LOC or CEN record. If one entry does not fit into the classic LOC or CEN record, only that entry is required to be moved into a ZIP64 extra field. The other entries may stay in the classic record. Therefore, not all entries shown in the following table might be stored in a ZIP64 extra field. However, if they appear, their order must be as shown in the table.

Sample file: https://1pb.skis.ltd/cars-cond.zip For example, entry 4baaabaced0c9e0ac0e3666c7d0ec7d0/rgb_0039.png will be missing in ParallelZipFile.

99991 commented 1 year ago

Thank you for your findings! The reason why only the first 0xFFFF files were loaded is that that I was not detecting ZIP64 EOCDs correctly. I pushed a quick fix which works for your zip file, but I think there is a more proper way to do it. Perhaps I'll find time to fix this correctly someday. Might work now.