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] [Comment Edited] (COMPRESS-391) Zip entries alignment
Date Wed, 10 May 2017 16:43:04 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16004988#comment-16004988
] 

Zbynek Vyskovsky edited comment on COMPRESS-391 at 5/10/17 4:43 PM:
--------------------------------------------------------------------

I thought it zipalign aligns .so files to page boundary but maybe I forgot details.

With the latest changes I'd only afraid that padding can only grow, maybe we can reset (subtract
the existing padding) before we calculate new one (only in case the alignment check failed,
as you implemented it).

Extra field 4.6.10 could work if we don't want to store the alignment, good catch.

Anyway, I sent the proposal so let see if it's approved, we may then modify the solution (and
sure, I meant 1 instead of l :-) ):

{code}
   4.6.11 -Data Stream Alignment (0xa11e):

      Defines alignment of data stream of this entry within the zip
      archive. Additionally, indicates whether the compression
      method should be kept when re-compressing the zip file.

      The purpose of this extra field is to align specific resources
      to word or page boundary so they can be easily mapped into
      memory.  

         Value         Size        Description
         -----         ----        -----------
         0xa11e        Short       tag for this extra block type
         TSize         Short       total data size for this block (2+padding)
         alignment     Short       required alignment and indicator
         0x00          Variable    padding

      The alignment field (lower 15 bits) defines the minimal alignment
      required by the data stream.
      Bit 15 of alignment field indicates whether compression method
      of this entry can be changed when recompressing the zip file.
      0 means the compression method should be kept, 1 indicates
      the compression method can be changed.

      The padding field contains padding to ensure the correct alignment
      and can be changed at any time when the offset changes or required
      alignment changes.
{code}


was (Author: kvr):
I thought it zipalign aligns .so files to page boundary but maybe I forgot details.

With the latest changes I'd only afraid that padding can only grow, maybe we can reset (subtract
the existing padding) before we calculate new one (only in case the alignment check failed,
as you implemented it).

Extra field 4.6.10 could work if we don't want to store the alignment, good catch.

Anyway, I sent the proposal so let see if it's approved, we may then modify the solution:

{code}
   4.6.11 -Data Stream Alignment (0xa11e):

      Defines alignment of data stream of this entry within the zip
      archive. Additionally, indicates whether the compression
      method should be kept when re-compressing the zip file.

      The purpose of this extra field is to align specific resources
      to word or page boundary so they can be easily mapped into
      memory.  

         Value         Size        Description
         -----         ----        -----------
         0xa11e        Short       tag for this extra block type
         TSize         Short       total data size for this block (2+padding)
         alignment     Short       required alignment and indicator
         0x00          Variable    padding

      The alignment field (lower 15 bits) defines the minimal alignment
      required by the data stream.
      Bit 15 of alignment field indicates whether compression method
      of this entry can be changed when recompressing the zip file.
      0 means the compression method should be kept, 1 indicates
      the compression method can be changed.

      The padding field contains padding to ensure the correct alignment
      and can be changed at any time when the offset changes or required
      alignment changes.
{code}

> 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