[
https://issues.apache.org/jira/browse/COMPRESS-565?focusedWorklogId=559149&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-559149
]
ASF GitHub Bot logged work on COMPRESS-565:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 01/Mar/21 01:20
Start Date: 01/Mar/21 01:20
Worklog Time Spent: 10m
Work Description: PeterAlfredLee commented on pull request #169:
URL: https://github.com/apache/commons-compress/pull/169#issuecomment-787572402
> 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.
Yes, it is. I pushed a new commit with only the javadoc of the new option
changed.
> 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.
This means we should encode the relative offset and disk number at the same
time - even through only eithor of them is too big. Am I right about it?
> Let's discuss this on the dev list.
+1.
----------------------------------------------------------------
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:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 559149)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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)
