[ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004052#comment-16004052 ]
Zbynek Vyskovsky commented on COMPRESS-391: ------------------------------------------- [~bodewig] : Oh, I should be faster in implementing the patches if I don't want to wait for another release :-) Thanks for this! I think first the field can be removed completely and then only added if the alignment doesn't match. Although with approach you mentioned the copying of alignment would still work as long as the old files streams and structure remains exactly the same... which is kind of fragile though... I believe it would still make sense to write the requested alignment value (not padding value) as part of the payload, it's just two bytes anyway and it may be used later when someone implements both reading and writing part. Additionally, in such case this extra field should be written always, not only when alignment doesn't match, as it contains important information for re-zipping. About zipalign: As far as I remember, they simply add enough zeroes at the end of extra fields, they even don't create the id header, its size etc. So the result is not really correct zip stream but I assume the readers simply ignore it. So no "prior art" here... About Zip RFC: According to https://support.pkware.com/display/PKZIP/APPNOTE , there is an e-mail for proposing enhancements. I can write and update here. 0xalle (id), 0x0002 (size), short (alignment) sounds good? :-) > Zip entries alignment > --------------------- > > Key: COMPRESS-391 > URL: https://issues.apache.org/jira/browse/COMPRESS-391 > Project: Commons Compress > Issue Type: New Feature > Components: Archivers > Affects Versions: 1.13 > Reporter: Zbynek Vyskovsky > Labels: features, github-import, patch > Fix For: 1.14 > > > Similarly to COMPRESS-390, there are requirements of the zip content to be > mapped directly into memory and therefore may require special alignment on > the embedded files. E.g. libraries may be aligned to page (4096-bytes) > boundary, images on 4-bytes boundary etc. By alignment it's meant the offset > from the beginning of file where the actual data stream starts, not the > header. > One of the cases was (still is?) Android APK for which zipalign utility was > created. > It would be useful if commons-compress ZipArchiveOutputStream supports > something similar directly in its API. -- This message was sent by Atlassian JIRA (v6.3.15#6346)