https://bugs.documentfoundation.org/show_bug.cgi?id=163384
Michael Stahl (allotropia) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE See Also| |https://bugs.documentfounda | |tion.org/show_bug.cgi?id=16 | |2944 Status|UNCONFIRMED |RESOLVED --- Comment #11 from Michael Stahl (allotropia) <[email protected]> --- apparently bug 162944 was also about Apache POI, let's see... so if i look here: 00000160: 0144 312c e343 0e31 7cef e937 504b 0708 .D1,.C.1|..7PK.. 00000170: 912c 28bc 3b01 0000 0000 0000 1d04 0000 .,(.;........... 00000180: 0000 0000 504b 0304 2d00 0800 0800 0000 ....PK..-....... at 016C the data descriptor signature for the zip entry, at 0184 the signature of the local file header of the next zip entry... 0170-0173 CRC 0174-017B 64-bit size, LE: 13b 017C-0183 64-bit size, LE: 41d looks like a Zip64 DD? then we have the local file header: 00000000: 504b 0304 2d00 0800 0800 0000 0000 0000 PK..-........... 00000010: 0000 0000 0000 0000 0000 1300 0000 5b43 ..............[C the extra field length at 001C-001D is 0 - so there is no Zip64 extra field, and no indication that this is a Zip64 entry. so the problem is the same as bug 162944. IMHO if there is no Zip64 entry field, a Zip consumer cannot be required to "guess" how long the data descriptor is; you either provide a Zip64 extra field and then the sizes are 64-bit, or you don't and then the sizes are 32-bit. also, see the Apache commons-compress code i found and pasted in https://bugs.documentfoundation.org/show_bug.cgi?id=162944#c7 ... it's unclear to me how such files can even be created. *** This bug has been marked as a duplicate of bug 162944 *** -- You are receiving this mail because: You are the assignee for the bug.
