[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Work logged] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutpu
From:       "ASF GitHub Bot (Jira)" <jira () apache ! org>
Date:       2021-02-27 10:51:00
Message-ID: JIRA.13358954.1613514611000.12005.1614423060098 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=558901&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-558901 \
]

ASF GitHub Bot logged work on COMPRESS-565:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 27/Feb/21 10:50
            Start Date: 27/Feb/21 10:50
    Worklog Time Spent: 10m 
      Work Description: bodewig commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-787053225


   I like the code change.
   
   It is good you always include a central directory zip64 when there has been one in \
LFH, something I likely would have overlooked. Thanks. The javadoc of the new option \
is not completely accurate, as it will always add zip64 entries to the central \
directory, but not necessarily encode the disk number and relative offset.  
   Oh, I believe we are overlooking something. We must ensure we add the relative LFH \
offset to the Zip64 extended information entry inside the central directory even if \
it is not too big in the case where the disk number is too big - or we'd create a gap \
inside of the extra field. This is currently wrong inside master as well, unless I'm \
wrong.  
   I don't like the name of the new option, but I'm the last one who should suggest a \
different one - I've got a long track record of picking bad names. Let's discuss this \
on the dev list.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 558901)
    Time Spent: 0.5h  (was: 20m)

> Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream
> -----------------------------------------------------------------------
> 
> Key: COMPRESS-565
> URL: https://issues.apache.org/jira/browse/COMPRESS-565
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
> Affects Versions: 1.20
> Reporter: Evgenii Bovykin
> Assignee: Peter Lee
> Priority: Major
> Attachments: commons-compress-1.21-SNAPSHOT.jar, image-2021-02-20-15-51-21-747.png
> 
> Time Spent: 0.5h
> Remaining Estimate: 0h
> 
> We've recently updated commons-compress library from version 1.9 to 1.20 and now \
> experiencing the problem that didn't occur before. 
> When using  ZipArchiveOutputStream to archive 5Gb file and setting the following \
> fields {{output.setUseZip64(Zip64Mode.Always)}}
> {{output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)}}
>  resulting archive contains corrupted headers.
> *Expand-Archive Powershell utility cannot extract the archive at all with the error \
> about corrupted header. 7zip also complains about it, but can extract the archive.* \
>  The problem didn't appear when using library version 1.9.
> 
> I've created a sample project that reproduces the error -  \
> [https://github.com/missingdays/commons-compress-example] Issue doesn't reproduce \
> if you do any of the following: 
> # Downgrade library to version 1.9
> # Remove output.setCreateUnicodeExtraFields(ZipArchiveOutputStream.UnicodeExtraFieldPolicy.ALWAYS)
>  # Remove  output.setUseZip64(Zip64Mode.Always) and zip smaller file (e.g. 1Gb)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[prev in list] [next in list] [prev in thread] [next in thread]