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

Stefan Bodewig commented on COMPRESS-565:
-----------------------------------------

There are known incompatibilities with our Zip64 implementation and what Excel 
expects, see https://issues.apache.org/jira/browse/COMPRESS-474 and I wouldn't 
be surprised if PowerShell used the same code. But this should only cause 
problems if the archive contains files smaller than 4GB and not be related to 
Unicode Extra Fields at all.

Please include the exact error messages when reporting an interoperability 
issue not just "error about corrupted headers". If a tool fails to extract 
archives created by Commons Compress than it could be the fault of either side 
- given the spec is vague enough and implementations differ in their 
interpretation of it.

> 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: image-2021-02-20-15-51-21-747.png
>
>
> 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)

Reply via email to