commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-391) Zip entries alignment
Date Fri, 05 May 2017 14:43:04 GMT


ASF GitHub Bot commented on COMPRESS-391:

Github user bodewig commented on the issue:
    I don't see a chance of making it independent of `ZipArchiveOutputStream`, you are certainly
    I was thinking along the lines of `ZipArchiveOutputStream` calculates the length needed
for proper alignment, creates an instance of the new extra field passing in the size information
necessary and adds it to the `ZipArchiveEntry` - after that the code in `ZipArchiveOutputStream`
can be left unchanged.

> Zip entries alignment
> ---------------------
>                 Key: COMPRESS-391
>                 URL:
>             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

View raw message