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