bodewig edited a comment on pull request #169: URL: https://github.com/apache/commons-compress/pull/169#issuecomment-788865243
> This means we should encode the relative offset and disk number at the same time - even through only eithor of them is too big. Am I right about it? No, this is not what I meant. In the layout of the ZIP64 extended information extra field you have the two sizes - which must always be present - then the LFH offset, then the disk number. If you don't need to encode the LFH offset but have to encode the disk number the disk number would appear directly after the sizes. I'm afraid there might be parsers that try to read the LFH offset anyway if the size of the extra field is bigger than the two size fields. So I'd encode both, even if only the disk number needs to be encoded - and would be willing to encode the LFH offset (when needed) without encoding the disk number. I may be overcautious (the parser should consult the corresponding field inside of the central directory actually contains FFs and it should see the size is only 20 bytes not 24 or even 28) but prefer to stay on the safe side. Also, this is an edge case of an edge case - I don't expect us to ever create archives with more than 64k parts. `AlwaysWithCompatibility` sounds a lot better, thanks :-) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
