[
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)
