commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zbynek Vyskovsky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-391) Zip entries alignment
Date Tue, 09 May 2017 15:05:04 GMT

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

Mime
View raw message