[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-03-06 Thread Stefan Bodewig (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated COMPRESS-565:

Fix Version/s: 1.21

> 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
> Fix For: 1.21
>
> Attachments: commons-compress-1.21-SNAPSHOT.jar, 
> image-2021-02-20-15-51-21-747.png
>
>  Time Spent: 2.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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-20 Thread Stefan Bodewig (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated COMPRESS-565:

Attachment: commons-compress-1.21-SNAPSHOT.jar

> 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
>
>
> 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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-19 Thread Peter Lee (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Lee updated COMPRESS-565:
---
Attachment: image-2021-02-20-15-51-21-747.png

> 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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-16 Thread Peter Lee (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Lee updated COMPRESS-565:
---
Assignee: Peter Lee

> 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
>
> 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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-16 Thread Evgenii Bovykin (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Bovykin updated COMPRESS-565:
-
Description: 
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 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)

  was:
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 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)


> 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
>Priority: Major
>
> 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 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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-16 Thread Evgenii Bovykin (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Bovykin updated COMPRESS-565:
-
Description: 
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)

  was:
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 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)


> 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
>Priority: Major
>
> 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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-16 Thread Evgenii Bovykin (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Bovykin updated COMPRESS-565:
-
Description: 
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 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)

  was:
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 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|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)


> 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
>Priority: Major
>
> 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 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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-16 Thread Evgenii Bovykin (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Bovykin updated COMPRESS-565:
-
Description: 
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 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|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)

  was:
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 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)


> 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
>Priority: Major
>
> 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 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|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)


[jira] [Updated] (COMPRESS-565) Regression - Corrupted headers when using 64 bit ZipArchiveOutputStream

2021-02-16 Thread Evgenii Bovykin (Jira)


 [ 
https://issues.apache.org/jira/browse/COMPRESS-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Bovykin updated COMPRESS-565:
-
Description: 
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 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)

  was:
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 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)


> 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
>Priority: Major
>
> 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 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)