[
https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002836#comment-16002836
]
Zbynek Vyskovsky commented on COMPRESS-391:
-------------------------------------------
[~bodewig] : Looks like it should work, I think it might make sense to take the
length from extra once re-populated but that's fine. I'm also wondering what
happens when someone copies the zip stream, it would copy this padding to the
output (and potentially add new one if requested), right? That wouldn't make
too much sense as the purpose of this field is not really padding but alignment
of the stream.
When you suggested it, I started thinking more about self-maintaining solution.
First step is the same, i.e. creating extra field called FileAlignment (I
prefer the name alignment because it better expresses its purpose). That would
be encoded as variable length depending on the required padding but two bytes
would be mandatory, containing the requested alignment. Therefore it would be
possible to read the previously requested alignment from existing zip file and
pass it to another one. It would also make sense to assign it some reasonable
id as it got some meaning (and maybe send request to add to Zip RFC).
The class would still require special handling as there should be just single
instance and whenever setAlignment() is called we would have to replace the old
instance (actually we wouldn't need setAlignment anymore really but maybe it
could be useful if added to common interface and making it reusable across
other implementations). As well as it would require special handling during
serialization - it should be ignored first when constructing extra fields
array, then padding should be added and only then should be appended to extra
field. Because of this I feel the original code was actually better as it
required special handling only at one place.
What are your thoughts? And Sorry I haven't responded earlier, it's more
complex and I haven't found time to look at this yet.
> 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)
