[jira] [Resolved] (COMPRESS-519) Decompression fails with IllegalArgumentException: fromIndex(50) > toIndex(49)
[
https://issues.apache.org/jira/browse/COMPRESS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-519.
-
Resolution: Fixed
fixed with commit ea37bc16
> Decompression fails with IllegalArgumentException: fromIndex(50) > toIndex(49)
> --
>
> Key: COMPRESS-519
> URL: https://issues.apache.org/jira/browse/COMPRESS-519
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.IllegalArgumentException: fromIndex(50)
> > toIndex(49)
> at java.base/java.util.Arrays.rangeCheck(Arrays.java:116)
> at java.base/java.util.Arrays.fill(Arrays.java:3516)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:670)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:332)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:136)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:113)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:368)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:93)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x09, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00, 0x42, 0x5a, 0x68, 0x34, 0x31, 0x41, 0x59, 0x26, 0x53,
> 0x59, 0x62, 0xe4, 0x4f, 0x51, 0x80, 0x00, 0x0d, 0xd1, 0x80,
> 0x00, 0x10, 0x40, 0x00, 0x35, 0xf9, 0x8b, 0x00, 0x20, 0x00,
> 0x48, 0x89, 0xfa, 0x94, 0xf2, 0x9e, 0x29, 0xe8, 0xd2, 0x00,
> 0x00, 0x22, 0x00, 0x00, 0x00, 0x50, 0x4b, 0x03, 0x04, 0x14,
> 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (COMPRESS-523) Decompression fails with IllegalArgumentException
[
https://issues.apache.org/jira/browse/COMPRESS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-523.
-
Resolution: Fixed
fixed with commit 2ea0e464
> Decompression fails with IllegalArgumentException
> -
>
> Key: COMPRESS-523
> URL: https://issues.apache.org/jira/browse/COMPRESS-523
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.IllegalArgumentException
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.realSkip(ZipArchiveInputStream.java:1120)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.skipRemainderOfArchive(ZipArchiveInputStream.java:1054)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:283)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:15)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x01, 0x02, 0x14, 0x00, 0x14, 0x00, 0x08, 0x00,
> 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x43, 0xbe, 0x00, 0x00,
> 0x00, 0xb7, 0xe8, 0x07, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (COMPRESS-518) Decompression fails with ClassCastException
[
https://issues.apache.org/jira/browse/COMPRESS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-518.
-
Resolution: Fixed
fixed with commit 1793167c
I've also fixed similar bugs (assuming a certain extra field must be of a given
type) in {{ZipFile}} and {{ZipArchiveOutputStream}} as well.
> Decompression fails with ClassCastException
> ---
>
> Key: COMPRESS-518
> URL: https://issues.apache.org/jira/browse/COMPRESS-518
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.ClassCastException: class
> org.apache.commons.compress.archivers.zip.UnrecognizedExtraField cannot be
> cast to class
> org.apache.commons.compress.archivers.zip.Zip64ExtendedInformationExtraField
> (org.apache.commons.compress.archivers.zip.UnrecognizedExtraField and
> org.apache.commons.compress.archivers.zip.Zip64ExtendedInformationExtraField
> are in unnamed module of loader 'app')
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.processZip64Extra(ZipArchiveInputStream.java:419)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:347)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:88)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x01, 0x00, 0x09, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (COMPRESS-517) Decompression fails with NullPointerException
[
https://issues.apache.org/jira/browse/COMPRESS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-517.
-
Resolution: Fixed
fixed with commit f71d3ddd
> Decompression fails with NullPointerException
> -
>
> Key: COMPRESS-517
> URL: https://issues.apache.org/jira/browse/COMPRESS-517
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestamp.getLocalFileDataData(X5455_ExtendedTimestamp.java:180)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.mergeLocalFileDataData(ExtraFieldUtils.java:250)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:691)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtraFields(ZipArchiveEntry.java:415)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.mergeExtraFields(ZipArchiveEntry.java:893)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:676)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:341)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:88)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x01, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (COMPRESS-516) Decompression fails with ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/COMPRESS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-516.
-
Resolution: Fixed
fixed with commit 3497dcbc
> Decompression fails with ArrayIndexOutOfBoundsException
> ---
>
> Key: COMPRESS-516
> URL: https://issues.apache.org/jira/browse/COMPRESS-516
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array
> index out of range: 16777295
> at java.base/java.util.Arrays.rangeCheck(Arrays.java:123)
> at java.base/java.util.Arrays.fill(Arrays.java:3516)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:670)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:332)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:136)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:113)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:368)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:97)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
>
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x09, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00, 0x42, 0x5a, 0x68, 0x34, 0x31, 0x41, 0x59, 0x26, 0x53,
> 0x59, 0x62, 0xe4, 0x4f, 0x51, 0x00, 0x00, 0x0d, 0xd1, 0x80,
> 0x00, 0x10, 0x40, 0x00, 0x35, 0xf9, 0x8b, 0x00, 0x20, 0x00,
> 0x48, 0x89, 0xfa, 0x94, 0xf2, 0x9e, 0x29, 0xe8, 0xd2, 0x11,
> 0x8a, 0x4f, 0x53, 0x34, 0x0f, 0x51, 0x7a, 0xed, 0x86, 0x65,
> 0xd6, 0xed, 0x61, 0xee, 0x68, 0x89, 0x48, 0x7d, 0x07, 0x71,
> 0x92, 0x2a, 0x50, 0x60, 0x04, 0x95, 0x61, 0x35, 0x47, 0x73,
> 0x31, 0x29, 0xc2, 0xdd, 0x5e, 0xc7, 0x4a, 0x15, 0x14, 0x32,
> 0x4c, 0xda, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-516) Decompression fails with ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/COMPRESS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114870#comment-17114870
]
Stefan Bodewig commented on COMPRESS-516:
-
Thanks, this is very similar to COMPRESS-424 and back then I only looked for
indexed access to the internal arrays and overlooked the {{fill}} case.
> Decompression fails with ArrayIndexOutOfBoundsException
> ---
>
> Key: COMPRESS-516
> URL: https://issues.apache.org/jira/browse/COMPRESS-516
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array
> index out of range: 16777295
> at java.base/java.util.Arrays.rangeCheck(Arrays.java:123)
> at java.base/java.util.Arrays.fill(Arrays.java:3516)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:670)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:332)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:136)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:113)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:368)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:97)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
>
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x09, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00, 0x42, 0x5a, 0x68, 0x34, 0x31, 0x41, 0x59, 0x26, 0x53,
> 0x59, 0x62, 0xe4, 0x4f, 0x51, 0x00, 0x00, 0x0d, 0xd1, 0x80,
> 0x00, 0x10, 0x40, 0x00, 0x35, 0xf9, 0x8b, 0x00, 0x20, 0x00,
> 0x48, 0x89, 0xfa, 0x94, 0xf2, 0x9e, 0x29, 0xe8, 0xd2, 0x11,
> 0x8a, 0x4f, 0x53, 0x34, 0x0f, 0x51, 0x7a, 0xed, 0x86, 0x65,
> 0xd6, 0xed, 0x61, 0xee, 0x68, 0x89, 0x48, 0x7d, 0x07, 0x71,
> 0x92, 0x2a, 0x50, 0x60, 0x04, 0x95, 0x61, 0x35, 0x47, 0x73,
> 0x31, 0x29, 0xc2, 0xdd, 0x5e, 0xc7, 0x4a, 0x15, 0x14, 0x32,
> 0x4c, 0xda, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-514) SevenZFile fails with encoded header over 2GiB
[
https://issues.apache.org/jira/browse/COMPRESS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114860#comment-17114860
]
Stefan Bodewig commented on COMPRESS-514:
-
There are a few places where the 7z format says a certain value is a UINT64 and
we store it inside of a Java long at best. Even if we fix this particular case
in some way there will be more problems lurking (that I hope we all catch
before they cause ArrayIndexOutOufBoundsExceptions or similar things). Because
of this I'd be fine with listing the known limitations.
If we decide to deal with this specific problem then I'd prefer a solution that
doesn't penalize the normal case too much and doesn't hide problems we can find
early with the existing code. As long as we detect a bad CRC inside of
SevenZFile's constructor, your option 3 sounds reasonable. Nobody would see and
use the "bad" data, or am I overlooking something?
> SevenZFile fails with encoded header over 2GiB
> --
>
> Key: COMPRESS-514
> URL: https://issues.apache.org/jira/browse/COMPRESS-514
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: A Kelday
>Priority: Minor
> Attachments: HeaderChannelBuffer.java
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When reading what some may call a large encrypted 7zip file (1.2TB with 22
> million files), the read fails at the header stage with the trace below. Is
> this within the spec? I've written some code to handle it, because I did
> actually need to extract the file in java. If that's of any use I can provide
> it (it's a naive wrapper that just pages in a buffer at a time).
>
> {code:java}
> Exception in thread "main" java.io.IOException: Cannot handle
> unpackSize241696
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.assertFitsIntoInt(SevenZFile.java:1523)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readEncodedHeader(SevenZFile.java:622)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.initializeArchive(SevenZFile.java:532)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readHeaders(SevenZFile.java:468)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:337)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:129)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:116)
> {code}
> 7zip itself can also open it (and display/extract etc.), here are the stats:
>
>
> {code:java}
> Size: 2 489 903 580 875
> Packed Size: 1 349 110 308 832
> Folders: 40 005
> Files: 22 073 957
> CRC: E26F6A96
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (COMPRESS-404) Add Path equivalents to TarArchiveEntry, with methods using File delegating to equivalents
[
https://issues.apache.org/jira/browse/COMPRESS-404?focusedWorklogId=436775=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-436775
]
ASF GitHub Bot logged work on COMPRESS-404:
---
Author: ASF GitHub Bot
Created on: 23/May/20 15:38
Start Date: 23/May/20 15:38
Worklog Time Spent: 10m
Work Description: bodewig commented on a change in pull request #97:
URL: https://github.com/apache/commons-compress/pull/97#discussion_r429556041
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
##
@@ -695,6 +784,15 @@ public void setModTime(final Date time) {
modTime = time.getTime() / MILLIS_PER_SECOND;
}
+/**
+ * Set this entry's modification time.
+ *
+ * @param time This entry's new modification time.
+ */
+public void setModTime(final FileTime time) {
Review comment:
please add a since tag
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
##
@@ -724,11 +822,26 @@ public boolean isCheckSumOK() {
* Get this entry's file.
*
* This method is only useful for entries created from a {@code
- * File} but not for entries read from an archive.
+ * File} or {@code Path} but not for entries read from an archive.
*
- * @return This entry's file.
+ * @return This entry's file or null if the entry was not created from a
file.
*/
public File getFile() {
+if (file == null) {
+return null;
+}
+return file.toFile();
+}
+
+/**
+ * Get this entry's file.
+ *
+ * This method is only useful for entries created from a {@code
+ * File} or {@code Path} but not for entries read from an archive.
+ *
+ * @return This entry's file or null if the entry was not created from a
file.
+ */
+public Path getPath() {
Review comment:
please add a since tag
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: 436775)
Time Spent: 3h (was: 2h 50m)
> Add Path equivalents to TarArchiveEntry, with methods using File delegating
> to equivalents
> --
>
> Key: COMPRESS-404
> URL: https://issues.apache.org/jira/browse/COMPRESS-404
> Project: Commons Compress
> Issue Type: Sub-task
>Reporter: Simon Spero
>Priority: Minor
> Time Spent: 3h
> Remaining Estimate: 0h
>
> (This is a reasonable place to start, as Paths give better access to
> tar-relevant metadata on unix system).
> Symlink info is easier to obtain
> Unix based Paths allow access to useful attributes under "unix:*"
> - numeric uid and gid
> - string owner and group names
> - mtime,ctime,atime
> - numeric mode
> - numeric dev and inode
> - numeric rdev
> - Linux, Solaris and Windows allow access to extended attributes
> (MacOS X xattrs aren't supported as of jdk 9)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] bodewig commented on a change in pull request #97: COMPRESS-404: Use java.nio.Path in TarArchiveEntry
bodewig commented on a change in pull request #97:
URL: https://github.com/apache/commons-compress/pull/97#discussion_r429556041
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
##
@@ -695,6 +784,15 @@ public void setModTime(final Date time) {
modTime = time.getTime() / MILLIS_PER_SECOND;
}
+/**
+ * Set this entry's modification time.
+ *
+ * @param time This entry's new modification time.
+ */
+public void setModTime(final FileTime time) {
Review comment:
please add a since tag
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
##
@@ -724,11 +822,26 @@ public boolean isCheckSumOK() {
* Get this entry's file.
*
* This method is only useful for entries created from a {@code
- * File} but not for entries read from an archive.
+ * File} or {@code Path} but not for entries read from an archive.
*
- * @return This entry's file.
+ * @return This entry's file or null if the entry was not created from a
file.
*/
public File getFile() {
+if (file == null) {
+return null;
+}
+return file.toFile();
+}
+
+/**
+ * Get this entry's file.
+ *
+ * This method is only useful for entries created from a {@code
+ * File} or {@code Path} but not for entries read from an archive.
+ *
+ * @return This entry's file or null if the entry was not created from a
file.
+ */
+public Path getPath() {
Review comment:
please add a since tag
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
[jira] [Work logged] (COMPRESS-404) Add Path equivalents to TarArchiveEntry, with methods using File delegating to equivalents
[
https://issues.apache.org/jira/browse/COMPRESS-404?focusedWorklogId=436774=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-436774
]
ASF GitHub Bot logged work on COMPRESS-404:
---
Author: ASF GitHub Bot
Created on: 23/May/20 15:35
Start Date: 23/May/20 15:35
Worklog Time Spent: 10m
Work Description: bodewig commented on a change in pull request #97:
URL: https://github.com/apache/commons-compress/pull/97#discussion_r429555828
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
##
@@ -368,10 +397,74 @@ public TarArchiveEntry(final File file) {
* @param fileName the name to be used for the entry.
*/
public TarArchiveEntry(final File file, final String fileName) {
+final String normalizedName = normalizeFileName(fileName, false);
+this.file = file.toPath();
+
+try {
+readFileMode(this.file, normalizedName);
+} catch (IOException e) {
+// Ignore for backwards compatibility
Review comment:
Ignoring exceptions here - and documenting that we do - seems to be the
best approach.
Another alternative would be to not change this constructor's code to use
the new methods at all. If we want to invoke the new methods then I'd suggest
to set `modTime` and `size` "the old way" before invoking the new methods so
we keep the old behaviour if things go wrong in NIO land.
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: 436774)
Time Spent: 2h 50m (was: 2h 40m)
> Add Path equivalents to TarArchiveEntry, with methods using File delegating
> to equivalents
> --
>
> Key: COMPRESS-404
> URL: https://issues.apache.org/jira/browse/COMPRESS-404
> Project: Commons Compress
> Issue Type: Sub-task
>Reporter: Simon Spero
>Priority: Minor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> (This is a reasonable place to start, as Paths give better access to
> tar-relevant metadata on unix system).
> Symlink info is easier to obtain
> Unix based Paths allow access to useful attributes under "unix:*"
> - numeric uid and gid
> - string owner and group names
> - mtime,ctime,atime
> - numeric mode
> - numeric dev and inode
> - numeric rdev
> - Linux, Solaris and Windows allow access to extended attributes
> (MacOS X xattrs aren't supported as of jdk 9)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] bodewig commented on a change in pull request #97: COMPRESS-404: Use java.nio.Path in TarArchiveEntry
bodewig commented on a change in pull request #97:
URL: https://github.com/apache/commons-compress/pull/97#discussion_r429555828
##
File path:
src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
##
@@ -368,10 +397,74 @@ public TarArchiveEntry(final File file) {
* @param fileName the name to be used for the entry.
*/
public TarArchiveEntry(final File file, final String fileName) {
+final String normalizedName = normalizeFileName(fileName, false);
+this.file = file.toPath();
+
+try {
+readFileMode(this.file, normalizedName);
+} catch (IOException e) {
+// Ignore for backwards compatibility
Review comment:
Ignoring exceptions here - and documenting that we do - seems to be the
best approach.
Another alternative would be to not change this constructor's code to use
the new methods at all. If we want to invoke the new methods then I'd suggest
to set `modTime` and `size` "the old way" before invoking the new methods so
we keep the old behaviour if things go wrong in NIO land.
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
[jira] [Work logged] (COMPRESS-520) Implement ZCompressorInputStreamTest without powermock
[
https://issues.apache.org/jira/browse/COMPRESS-520?focusedWorklogId=436773=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-436773
]
ASF GitHub Bot logged work on COMPRESS-520:
---
Author: ASF GitHub Bot
Created on: 23/May/20 15:16
Start Date: 23/May/20 15:16
Worklog Time Spent: 10m
Work Description: bodewig commented on pull request #101:
URL: https://github.com/apache/commons-compress/pull/101#issuecomment-633073993
Many thanks @theobisproject
Actually it is nice you have created an issue but we don't require a Jira
issue for every PR. Personally I prefer Jira if something needs discussion and
skip it when talking about a straight forward PR. YMMV
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: 436773)
Time Spent: 40m (was: 0.5h)
> Implement ZCompressorInputStreamTest without powermock
> --
>
> Key: COMPRESS-520
> URL: https://issues.apache.org/jira/browse/COMPRESS-520
> Project: Commons Compress
> Issue Type: Improvement
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Priority: Trivial
> Fix For: 1.21
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The ZCompressorInputStreamTest uses powermock to mock an empty enumeration.
> This prevents the test to be run on Java 9+.
> The same behaviour can be achieved by using {{Collections.emptyEnumeration}}
> and therefore the powermock dependency for the tests dropped.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] bodewig commented on pull request #101: COMPRESS-520: Implement ZCompressorInputStreamTest without powermock
bodewig commented on pull request #101: URL: https://github.com/apache/commons-compress/pull/101#issuecomment-633073993 Many thanks @theobisproject Actually it is nice you have created an issue but we don't require a Jira issue for every PR. Personally I prefer Jira if something needs discussion and skip it when talking about a straight forward PR. YMMV 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
[GitHub] [commons-compress] bodewig merged pull request #101: COMPRESS-520: Implement ZCompressorInputStreamTest without powermock
bodewig merged pull request #101: URL: https://github.com/apache/commons-compress/pull/101 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
[jira] [Work logged] (COMPRESS-520) Implement ZCompressorInputStreamTest without powermock
[
https://issues.apache.org/jira/browse/COMPRESS-520?focusedWorklogId=436772=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-436772
]
ASF GitHub Bot logged work on COMPRESS-520:
---
Author: ASF GitHub Bot
Created on: 23/May/20 15:11
Start Date: 23/May/20 15:11
Worklog Time Spent: 10m
Work Description: bodewig merged pull request #101:
URL: https://github.com/apache/commons-compress/pull/101
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: 436772)
Time Spent: 0.5h (was: 20m)
> Implement ZCompressorInputStreamTest without powermock
> --
>
> Key: COMPRESS-520
> URL: https://issues.apache.org/jira/browse/COMPRESS-520
> Project: Commons Compress
> Issue Type: Improvement
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Priority: Trivial
> Fix For: 1.21
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The ZCompressorInputStreamTest uses powermock to mock an empty enumeration.
> This prevents the test to be run on Java 9+.
> The same behaviour can be achieved by using {{Collections.emptyEnumeration}}
> and therefore the powermock dependency for the tests dropped.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-524) Mailing list addresses are out of date
[ https://issues.apache.org/jira/browse/COMPRESS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114808#comment-17114808 ] Stefan Bodewig commented on COMPRESS-524: - I believe we inherit this from the parent POM and I really don't know enough about the site plugin to know whether this has been introduced via a changed version of the site-plugin or the parent POM's configuration should be any different. If there is something that needs to be changed in the parent POM then the correct Jira component would be COMMONSSITE. > Mailing list addresses are out of date > -- > > Key: COMPRESS-524 > URL: https://issues.apache.org/jira/browse/COMPRESS-524 > Project: Commons Compress > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > Spot checking it looks like the links on > [https://commons.apache.org/proper/commons-compress/mailing-lists.html] are > all 404 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COMPRESS-524) Mailing list addresses are out of date
[ https://issues.apache.org/jira/browse/COMPRESS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114775#comment-17114775 ] Elliotte Rusty Harold commented on COMPRESS-524: Yes, the archive links seem to work. The others don't. > Mailing list addresses are out of date > -- > > Key: COMPRESS-524 > URL: https://issues.apache.org/jira/browse/COMPRESS-524 > Project: Commons Compress > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > Spot checking it looks like the links on > [https://commons.apache.org/proper/commons-compress/mailing-lists.html] are > all 404 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COMPRESS-524) Mailing list addresses are out of date
[ https://issues.apache.org/jira/browse/COMPRESS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114678#comment-17114678 ] Stefan Bodewig commented on COMPRESS-524: - [~elharo] you are talking about the (un)subscribe and post links which should be mailto links, right? the archive links seem to work for me. > Mailing list addresses are out of date > -- > > Key: COMPRESS-524 > URL: https://issues.apache.org/jira/browse/COMPRESS-524 > Project: Commons Compress > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Major > > Spot checking it looks like the links on > [https://commons.apache.org/proper/commons-compress/mailing-lists.html] are > all 404 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMPRESS-523) Decompression fails with IllegalArgumentException
[
https://issues.apache.org/jira/browse/COMPRESS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-523:
Fix Version/s: 1.21
> Decompression fails with IllegalArgumentException
> -
>
> Key: COMPRESS-523
> URL: https://issues.apache.org/jira/browse/COMPRESS-523
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.IllegalArgumentException
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.realSkip(ZipArchiveInputStream.java:1120)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.skipRemainderOfArchive(ZipArchiveInputStream.java:1054)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:283)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:15)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x01, 0x02, 0x14, 0x00, 0x14, 0x00, 0x08, 0x00,
> 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x43, 0xbe, 0x00, 0x00,
> 0x00, 0xb7, 0xe8, 0x07, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-522) Decompression fails with IllegalStateException(Illegal LEN / NLEN values)
[
https://issues.apache.org/jira/browse/COMPRESS-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-522:
Fix Version/s: 1.21
> Decompression fails with IllegalStateException(Illegal LEN / NLEN values)
> -
>
> Key: COMPRESS-522
> URL: https://issues.apache.org/jira/browse/COMPRESS-522
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.IllegalStateException: Illegal LEN /
> NLEN values
> at
> org.apache.commons.compress.compressors.deflate64.HuffmanDecoder.switchToUncompressedState(HuffmanDecoder.java:174)
> at
> org.apache.commons.compress.compressors.deflate64.HuffmanDecoder.decode(HuffmanDecoder.java:139)
> at
> org.apache.commons.compress.compressors.deflate64.Deflate64CompressorInputStream.read(Deflate64CompressorInputStream.java:84)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:493)
> at java.base/java.io.InputStream.readNBytes(InputStream.java:396)
> at java.base/java.io.InputStream.readAllBytes(InputStream.java:333)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:17)
> at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x14, 0x00, 0x08, 0x00, 0x09, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
> 0x61, 0x4a, 0x84, 0x02, 0x40, 0x00, 0x01, 0x00, 0xff, 0xff
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-520) Implement ZCompressorInputStreamTest without powermock
[
https://issues.apache.org/jira/browse/COMPRESS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-520:
Fix Version/s: 1.21
> Implement ZCompressorInputStreamTest without powermock
> --
>
> Key: COMPRESS-520
> URL: https://issues.apache.org/jira/browse/COMPRESS-520
> Project: Commons Compress
> Issue Type: Improvement
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Priority: Trivial
> Fix For: 1.21
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The ZCompressorInputStreamTest uses powermock to mock an empty enumeration.
> This prevents the test to be run on Java 9+.
> The same behaviour can be achieved by using {{Collections.emptyEnumeration}}
> and therefore the powermock dependency for the tests dropped.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-518) Decompression fails with ClassCastException
[
https://issues.apache.org/jira/browse/COMPRESS-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-518:
Fix Version/s: 1.21
> Decompression fails with ClassCastException
> ---
>
> Key: COMPRESS-518
> URL: https://issues.apache.org/jira/browse/COMPRESS-518
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.ClassCastException: class
> org.apache.commons.compress.archivers.zip.UnrecognizedExtraField cannot be
> cast to class
> org.apache.commons.compress.archivers.zip.Zip64ExtendedInformationExtraField
> (org.apache.commons.compress.archivers.zip.UnrecognizedExtraField and
> org.apache.commons.compress.archivers.zip.Zip64ExtendedInformationExtraField
> are in unnamed module of loader 'app')
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.processZip64Extra(ZipArchiveInputStream.java:419)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:347)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:88)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x01, 0x00, 0x09, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-519) Decompression fails with IllegalArgumentException: fromIndex(50) > toIndex(49)
[
https://issues.apache.org/jira/browse/COMPRESS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-519:
Fix Version/s: 1.21
> Decompression fails with IllegalArgumentException: fromIndex(50) > toIndex(49)
> --
>
> Key: COMPRESS-519
> URL: https://issues.apache.org/jira/browse/COMPRESS-519
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.IllegalArgumentException: fromIndex(50)
> > toIndex(49)
> at java.base/java.util.Arrays.rangeCheck(Arrays.java:116)
> at java.base/java.util.Arrays.fill(Arrays.java:3516)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:670)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:332)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:136)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:113)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:368)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:93)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x09, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00, 0x42, 0x5a, 0x68, 0x34, 0x31, 0x41, 0x59, 0x26, 0x53,
> 0x59, 0x62, 0xe4, 0x4f, 0x51, 0x80, 0x00, 0x0d, 0xd1, 0x80,
> 0x00, 0x10, 0x40, 0x00, 0x35, 0xf9, 0x8b, 0x00, 0x20, 0x00,
> 0x48, 0x89, 0xfa, 0x94, 0xf2, 0x9e, 0x29, 0xe8, 0xd2, 0x00,
> 0x00, 0x22, 0x00, 0x00, 0x00, 0x50, 0x4b, 0x03, 0x04, 0x14,
> 0x00, 0x08, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-521) Decompression fails with IllegalStateException
[
https://issues.apache.org/jira/browse/COMPRESS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-521:
Fix Version/s: 1.21
> Decompression fails with IllegalStateException
> --
>
> Key: COMPRESS-521
> URL: https://issues.apache.org/jira/browse/COMPRESS-521
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.IllegalStateException: Attempt to read
> beyond memory: dist=9321
> at
> org.apache.commons.compress.compressors.deflate64.HuffmanDecoder$DecodingMemory.recordToBuffer(HuffmanDecoder.java:526)
> at
> org.apache.commons.compress.compressors.deflate64.HuffmanDecoder$HuffmanCodes.decodeNext(HuffmanDecoder.java:338)
> at
> org.apache.commons.compress.compressors.deflate64.HuffmanDecoder$HuffmanCodes.read(HuffmanDecoder.java:307)
> at
> org.apache.commons.compress.compressors.deflate64.HuffmanDecoder.decode(HuffmanDecoder.java:152)
> at
> org.apache.commons.compress.compressors.deflate64.Deflate64CompressorInputStream.read(Deflate64CompressorInputStream.java:84)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:493)
> at java.base/java.io.InputStream.readNBytes(InputStream.java:396)
> at java.base/java.io.InputStream.readAllBytes(InputStream.java:333)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:76)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0xb6, 0x00, 0x09, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0x00, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x0c, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x65, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00, 0x42, 0x5a, 0x68, 0x34
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-517) Decompression fails with NullPointerException
[
https://issues.apache.org/jira/browse/COMPRESS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-517:
Fix Version/s: 1.21
> Decompression fails with NullPointerException
> -
>
> Key: COMPRESS-517
> URL: https://issues.apache.org/jira/browse/COMPRESS-517
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.commons.compress.archivers.zip.X5455_ExtendedTimestamp.getLocalFileDataData(X5455_ExtendedTimestamp.java:180)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.mergeLocalFileDataData(ExtraFieldUtils.java:250)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:691)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtraFields(ZipArchiveEntry.java:415)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.mergeExtraFields(ZipArchiveEntry.java:893)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setExtra(ZipArchiveEntry.java:676)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:341)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:88)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x01, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-515) Add fileName/path info to ZipFile constructor IOException
[ https://issues.apache.org/jira/browse/COMPRESS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114676#comment-17114676 ] Stefan Bodewig commented on COMPRESS-515: - AFAICT we only need to record the change before we can close this issue. > Add fileName/path info to ZipFile constructor IOException > - > > Key: COMPRESS-515 > URL: https://issues.apache.org/jira/browse/COMPRESS-515 > Project: Commons Compress > Issue Type: Improvement >Reporter: Ian Lavallee >Priority: Major > > When trying to give the user the fileName or path of the cause of a Maven > error it was realized the change needs to be in this project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMPRESS-516) Decompression fails with ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/COMPRESS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-516:
Fix Version/s: 1.21
> Decompression fails with ArrayIndexOutOfBoundsException
> ---
>
> Key: COMPRESS-516
> URL: https://issues.apache.org/jira/browse/COMPRESS-516
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Maksim Zuev
>Priority: Major
> Fix For: 1.21
>
>
> This Kotlin code fails with exception
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array
> index out of range: 16777295
> at java.base/java.util.Arrays.rangeCheck(Arrays.java:123)
> at java.base/java.util.Arrays.fill(Arrays.java:3516)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:670)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:332)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:136)
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:113)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:368)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextEntry(ZipArchiveInputStream.java:435)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt:97)
> at ru.example.kotlinfuzzer.tests.CompressTestKt.main(CompressTest.kt)
>
> {code:java}
> import org.apache.commons.compress.archivers.ArchiveStreamFactory
> import java.io.ByteArrayInputStream
> fun main() {
> val bytes = listOf(
> 0x50, 0x4b, 0x03, 0x04, 0x2e, 0x00, 0x00, 0x00, 0x0c, 0x00,
> 0x84, 0xb6, 0xba, 0x46, 0x72, 0xb6, 0xfe, 0x77, 0x63, 0x00,
> 0x00, 0x00, 0x6b, 0x00, 0x00, 0x00, 0x03, 0x00, 0x1c, 0x00,
> 0x62, 0x62, 0x62, 0x55, 0x54, 0x09, 0x00, 0x03, 0xe7, 0xce,
> 0x64, 0x55, 0xf3, 0xce, 0x64, 0x55, 0x75, 0x78, 0x0b, 0x00,
> 0x01, 0x04, 0x5c, 0xf9, 0x01, 0x00, 0x04, 0x88, 0x13, 0x00,
> 0x00, 0x42, 0x5a, 0x68, 0x34, 0x31, 0x41, 0x59, 0x26, 0x53,
> 0x59, 0x62, 0xe4, 0x4f, 0x51, 0x00, 0x00, 0x0d, 0xd1, 0x80,
> 0x00, 0x10, 0x40, 0x00, 0x35, 0xf9, 0x8b, 0x00, 0x20, 0x00,
> 0x48, 0x89, 0xfa, 0x94, 0xf2, 0x9e, 0x29, 0xe8, 0xd2, 0x11,
> 0x8a, 0x4f, 0x53, 0x34, 0x0f, 0x51, 0x7a, 0xed, 0x86, 0x65,
> 0xd6, 0xed, 0x61, 0xee, 0x68, 0x89, 0x48, 0x7d, 0x07, 0x71,
> 0x92, 0x2a, 0x50, 0x60, 0x04, 0x95, 0x61, 0x35, 0x47, 0x73,
> 0x31, 0x29, 0xc2, 0xdd, 0x5e, 0xc7, 0x4a, 0x15, 0x14, 0x32,
> 0x4c, 0xda, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00
> ).map { it.toByte() }.toByteArray()
> val input = ByteArrayInputStream(bytes)
> ArchiveStreamFactory().createArchiveInputStream("zip", input).use { ais ->
> ais.nextEntry
> ais.readAllBytes()
> }
> }
> {code}
> IOException expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-515) Add fileName/path info to ZipFile constructor IOException
[ https://issues.apache.org/jira/browse/COMPRESS-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-515: Fix Version/s: 1.21 > Add fileName/path info to ZipFile constructor IOException > - > > Key: COMPRESS-515 > URL: https://issues.apache.org/jira/browse/COMPRESS-515 > Project: Commons Compress > Issue Type: Improvement >Reporter: Ian Lavallee >Priority: Major > Fix For: 1.21 > > > When trying to give the user the fileName or path of the cause of a Maven > error it was realized the change needs to be in this project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COMPRESS-512) "AsiExtraField is not a concrete class" with graalvm native-image
[
https://issues.apache.org/jira/browse/COMPRESS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114672#comment-17114672
]
Stefan Bodewig commented on COMPRESS-512:
-
well {{AsiExtraField}} *is* a concrete class. I'm not sure what we can do on
our side [~Jbbouille]
> "AsiExtraField is not a concrete class" with graalvm native-image
> -
>
> Key: COMPRESS-512
> URL: https://issues.apache.org/jira/browse/COMPRESS-512
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Jean-Baptiste
>Priority: Trivial
>
> Hi, I am trying to unzip a file using apache commons compress. It is working
> with in a "classical jvm" like OpenJDK 11 or even Graalvm 11 but when I
> convert it in native-image it fails to run with its exception:
> {code:java}
> picocli.CommandLine$ExecutionException: Error while calling command (void
> fr.gouv.vitam.troubleshoot.TroubleShooter.logForAll(fr.gouv.vitam.troubleshoot.pojo.Component[],java.nio.file.Path)
> throws java.io.IOException): java.lang.ExceptionInInitializerError
> at picocli.CommandLine.executeUserObject(CommandLine.java:1816)
> at picocli.CommandLine.access$900(CommandLine.java:145)
> at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2150)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2144)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2108)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:1975)
> at picocli.CommandLine.execute(CommandLine.java:1904)
> at
> fr.gouv.vitam.troubleshoot.TroubleShooter.main(TroubleShooter.java:165)
> Caused by: java.lang.ExceptionInInitializerError
> at
> com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:290)
> at java.lang.Class.ensureInitialized(DynamicHub.java:496)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setCentralDirectoryExtra(ZipArchiveEntry.java:700)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.readCentralDirectoryEntry(ZipFile.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:714)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
> at
> fr.gouv.vitam.troubleshoot.subcommands.ZipTroubleshootReader.extract(ZipTroubleshootReader.java:44)
> at
> fr.gouv.vitam.troubleshoot.subcommands.LogForAll.execute(LogForAll.java:28)
> at
> fr.gouv.vitam.troubleshoot.TroubleService.logForAll(TroubleService.java:41)
> at
> fr.gouv.vitam.troubleshoot.TroubleShooter.logForAll(TroubleShooter.java:119)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at picocli.CommandLine.executeUserObject(CommandLine.java:1802)
> ... 7 more
> Caused by: java.lang.RuntimeException: class
> org.apache.commons.compress.archivers.zip.AsiExtraField is not a concrete
> class
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:73)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
> at
> com.oracle.svm.core.hub.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:350)
> at
> com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:270)
> ... 20 more
> {code}
> The interesting part is that one I think:
> {code:java}
> org.apache.commons.compress.archivers.zip.AsiExtraField is not a concrete
> class at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:73)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
> {code}
> In order to build it in native image I am using the following configuration:
> {code:java}
>
> org.graalvm.nativeimage
> native-image-maven-plugin
> ${native-image-maven-plugin.version}
>
>
>
> ${NOT-compile-to-binary}
> troubleshooter
>
> fr.gouv.vitam.troubleshoot.TroubleShooter
>
> -H:ReflectionConfigurationFiles=classes/META-INF/native-image/picocli-generated/fr.grouv.vitam/troubloushouter/reflect-config.json
> -H:+ReportUnsupportedElementsAtRuntime
>
>
> native-image
>
> package
>
>
>
> {code}
>
> Do you have an idea ?
--
This
[jira] [Updated] (COMPRESS-510) Multiple retrievals of InputStream for same SevenZFile entry fails
[
https://issues.apache.org/jira/browse/COMPRESS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated COMPRESS-510:
Fix Version/s: 1.21
> Multiple retrievals of InputStream for same SevenZFile entry fails
> --
>
> Key: COMPRESS-510
> URL: https://issues.apache.org/jira/browse/COMPRESS-510
> Project: Commons Compress
> Issue Type: Bug
>Affects Versions: 1.20
>Reporter: Robin Schimpf
>Assignee: Peter Lee
>Priority: Major
> Fix For: 1.21
>
> Attachments: image-2020-04-22-16-55-08-369.png
>
>
> I was trying out the new random access for the 7z files and have one of our
> tests failing where we are trying to read the same entry multiple times
> without closing the archive.
> Reproducing test case (I added this locally to the SevenZFileTest class)
> {code:java}
> @Test
> public void retrieveInputStreamForEntryMultipleTimes() throws IOException {
> try (SevenZFile sevenZFile = new SevenZFile(getFile("bla.7z"))) {
> for (SevenZArchiveEntry entry : sevenZFile.getEntries()) {
> byte[] firstRead =
> IOUtils.toByteArray(sevenZFile.getInputStream(entry));
> byte[] secondRead =
> IOUtils.toByteArray(sevenZFile.getInputStream(entry));
> assertArrayEquals(firstRead, secondRead);
> }
> }
> }
> {code}
> The Exception thrown is
> {code:java}
> java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 2
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.buildDecodingStream(SevenZFile.java:1183)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.getInputStream(SevenZFile.java:1436)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFileTest.retrieveInputStreamForEntryMultipleTimes(SevenZFileTest.java:688)
> ...
> {code}
> A similar test case for e.g. zip works fine
> {code:java}
> @Test
> public void retrieveInputStreamForEntryMultipleTimes() throws IOException {
> try (ZipFile zipFile = new ZipFile(getFile("bla.zip"))) {
> Enumeration entry = zipFile.getEntries();
> while (entry.hasMoreElements()) {
> ZipArchiveEntry e = entry.nextElement();
> byte[] firstRead = IOUtils.toByteArray(zipFile.getInputStream(e));
> byte[] secondRead =
> IOUtils.toByteArray(zipFile.getInputStream(e));
> assertArrayEquals(firstRead, secondRead);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-509) The ambiguous behavior of the TarArchiveEntry.getName() method
[ https://issues.apache.org/jira/browse/COMPRESS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114667#comment-17114667 ] Stefan Bodewig commented on COMPRESS-509: - I'm fine with always adding a / at the end for directories. We should probably record the change before closing this issue. > The ambiguous behavior of the TarArchiveEntry.getName() method > -- > > Key: COMPRESS-509 > URL: https://issues.apache.org/jira/browse/COMPRESS-509 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.18, 1.20 >Reporter: Petr Vasak >Assignee: Peter Lee >Priority: Minor > Attachments: Main.java > > > Scenario: To tar an empty directory and then to untar it. When the name is > longer than 100 characters, no ending slash appears. > Example: see attachment > Part of the output: > .. > dir/aa/ > dir/aaa/ > dir/ > dir/a > .. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMPRESS-509) The ambiguous behavior of the TarArchiveEntry.getName() method
[ https://issues.apache.org/jira/browse/COMPRESS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-509: Fix Version/s: 1.21 > The ambiguous behavior of the TarArchiveEntry.getName() method > -- > > Key: COMPRESS-509 > URL: https://issues.apache.org/jira/browse/COMPRESS-509 > Project: Commons Compress > Issue Type: Bug > Components: Archivers >Affects Versions: 1.18, 1.20 >Reporter: Petr Vasak >Assignee: Peter Lee >Priority: Minor > Fix For: 1.21 > > Attachments: Main.java > > > Scenario: To tar an empty directory and then to untar it. When the name is > longer than 100 characters, no ending slash appears. > Example: see attachment > Part of the output: > .. > dir/aa/ > dir/aaa/ > dir/ > dir/a > .. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (COMPRESS-507) Commons Compress cannot be built with JDK14 due to Pack200 removal
[ https://issues.apache.org/jira/browse/COMPRESS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-507: Fix Version/s: 1.21 > Commons Compress cannot be built with JDK14 due to Pack200 removal > -- > > Key: COMPRESS-507 > URL: https://issues.apache.org/jira/browse/COMPRESS-507 > Project: Commons Compress > Issue Type: Bug > Components: Build, Compressors >Affects Versions: 1.20 >Reporter: Vincent Privat >Priority: Major > Fix For: 1.21 > > > Oracle dropped Pack200 in JDK14 as per > [https://bugs.openjdk.java.net/browse/JDK-8232022] > Someone expressed his will to maintain Pack200 here: > [https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/003979.html] > [https://github.com/pfirmstone/Pack200-ex-openjdk] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] coveralls edited a comment on pull request #159: Updated the fail() exceptions with Junit5.
coveralls edited a comment on pull request #159: URL: https://github.com/apache/commons-collections/pull/159#issuecomment-625612511 [](https://coveralls.io/builds/30984373) Coverage decreased (-0.004%) to 90.089% when pulling **aa05290ebf7afc195e03d32abf21d1ee20b2f3dd on dota17:junit5WithExceptions** into **9f37668d9243fc71178f0e94a2b560ef861a639a on apache:master**. 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
[jira] [Comment Edited] (FILEUPLOAD-303) Do not have dependency on javax.servlet
[
https://issues.apache.org/jira/browse/FILEUPLOAD-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114593#comment-17114593
]
Mohamed edited comment on FILEUPLOAD-303 at 5/23/20, 7:33 AM:
--
I think I've been misunderstood.
In other words in the *{{FileUploadBase}}* class there's two *deprecated*
methods : *{{isMultipartContent}}* & *{{parseRequest}}* which they are
dependent to the {{javax.servlet}} by there parameters. Event If I use
UploadContext with FileUpload class I have to add the {{javax.servlet}}
dependency because {{FileUpload}} extends {{FileUploadBase}} with the two
deprecated methods.
All I want is a new version of {{FileUploadBase *without* the two deprecated
methods. Hence I can use FileUpload without being forced to add dependecy to
}}{{javax.servlet (I'm not in a servlet based webapp).}}
was (Author: cherb):
I think I've been misunderstood.
In other words in the *{{FileUploadBase}}* class there's two *deprecated*
methods : *{{isMultipartContent}}* & *{{parseRequest}}* which they are
dependent to the {{javax.servlet}} by there parameters\{{. }}Event If I use
UploadContext with FileUpload class I have to add the {{javax.servlet}}
dependency because {{FileUpload}} extends {{FileUploadBase}} with the two
deprecated methods.\{{}}
All I want is a new version of {{FileUploadBase *without* the two deprecated
methods. Hence I can use FileUpload without being forced to add dependecy to
}}{{javax.servlet (I'm not in a servlet based webapp).}}{{}}
> Do not have dependency on javax.servlet
> ---
>
> Key: FILEUPLOAD-303
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-303
> Project: Commons FileUpload
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Mohamed
>Priority: Major
>
> I'm trying to use FileUpload in my playframework projet to parse a
> multipart/mixed request. Every thing works well if I add the *javax.servlet*
> depency, which I do not use completely.
>
> I have created my own RequestContext like:
>
> {{public static class PlayRequestContext implements UploadContext {}}
> {{ private final Http.Request request;}}
> {{ private final ByteString bodyBuffer;}}
> {{ public PlayRequestContext(Http.Request request) {}}
> {{ this.request = request;}}
> {{ bodyBuffer = request.body().asBytes();}}
> {{ }}}
> {{ @Override}}
> {{ public String getCharacterEncoding() {}}
> {{ return StandardCharsets.ISO_8859_1.displayName();}}
> {{ }}}
> {{ @Override}}
> {{ public String getContentType() {}}
> {{ return
> request.getHeaders().get(Http.HeaderNames.CONTENT_TYPE).orElseThrow(unexpectedCase());}}
> {{ }}}
> {{ @Override}}
> {{ @Deprecated}}
> {{ public int getContentLength() {}}
> {{ return 0;}}
> {{ }}}
> {{ @Override}}
> {{ public InputStream getInputStream() {}}
> {{ return new ByteArrayInputStream(bodyBuffer.toArray());}}
> {{ }}}
> {{ @Override}}
> {{ public long contentLength() {}}
> {{ return bodyBuffer.length();}}
> {{ }}}
> {{}}}
>
> Is it possible to have another version without any dependecny to
> javax.servlet ?
>
> I thinks this is a great solution for every web application, not only servlet
> dependent projects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (FILEUPLOAD-303) Do not have dependency on javax.servlet
[
https://issues.apache.org/jira/browse/FILEUPLOAD-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114593#comment-17114593
]
Mohamed edited comment on FILEUPLOAD-303 at 5/23/20, 7:33 AM:
--
I think I've been misunderstood.
In other words in the *{{FileUploadBase}}* class there's two *deprecated*
methods : *{{isMultipartContent}}* & *{{parseRequest}}* which they are
dependent to the {{javax.servlet}} by there parameters\{{. }}Event If I use
UploadContext with FileUpload class I have to add the {{javax.servlet}}
dependency because {{FileUpload}} extends {{FileUploadBase}} with the two
deprecated methods.\{{}}
All I want is a new version of {{FileUploadBase *without* the two deprecated
methods. Hence I can use FileUpload without being forced to add dependecy to
}}{{javax.servlet (I'm not in a servlet based webapp).}}{{}}
was (Author: cherb):
I think I've been misunderstood.
In other words in the *{{FileUploadBase}}* class there's two *deprecated*
methods *{{isMultipartContent}}* & *{{parseRequest}}* which they are dependent
to the {{javax.servlet}} by there parameters{{. }}Event If I use UploadContext
with FileUpload class I have to add the {{javax.servlet}} dependency because
{{FileUpload}} extends {{FileUploadBase}} with the two deprecated methods.{{}}
All I want is a new version of {{FileUploadBase *without* the two deprecated
methods. Hence I can use FileUpload without being forced to add dependecy to
}}{{javax.servlet (I'm not in a servlet based webapp).}}{{}}
> Do not have dependency on javax.servlet
> ---
>
> Key: FILEUPLOAD-303
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-303
> Project: Commons FileUpload
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Mohamed
>Priority: Major
>
> I'm trying to use FileUpload in my playframework projet to parse a
> multipart/mixed request. Every thing works well if I add the *javax.servlet*
> depency, which I do not use completely.
>
> I have created my own RequestContext like:
>
> {{public static class PlayRequestContext implements UploadContext {}}
> {{ private final Http.Request request;}}
> {{ private final ByteString bodyBuffer;}}
> {{ public PlayRequestContext(Http.Request request) {}}
> {{ this.request = request;}}
> {{ bodyBuffer = request.body().asBytes();}}
> {{ }}}
> {{ @Override}}
> {{ public String getCharacterEncoding() {}}
> {{ return StandardCharsets.ISO_8859_1.displayName();}}
> {{ }}}
> {{ @Override}}
> {{ public String getContentType() {}}
> {{ return
> request.getHeaders().get(Http.HeaderNames.CONTENT_TYPE).orElseThrow(unexpectedCase());}}
> {{ }}}
> {{ @Override}}
> {{ @Deprecated}}
> {{ public int getContentLength() {}}
> {{ return 0;}}
> {{ }}}
> {{ @Override}}
> {{ public InputStream getInputStream() {}}
> {{ return new ByteArrayInputStream(bodyBuffer.toArray());}}
> {{ }}}
> {{ @Override}}
> {{ public long contentLength() {}}
> {{ return bodyBuffer.length();}}
> {{ }}}
> {{}}}
>
> Is it possible to have another version without any dependecny to
> javax.servlet ?
>
> I thinks this is a great solution for every web application, not only servlet
> dependent projects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] dota17 commented on pull request #159: Updated the fail() exceptions with Junit5.
dota17 commented on pull request #159: URL: https://github.com/apache/commons-collections/pull/159#issuecomment-633001505 Hi @garydgregory Under the folder commons-collections/src/test/java/org/apache/commons/collections4 (junit5WithExceptions), I executed the command to get the fails without annotate and import. `grep -R fail * | grep -v import |grep -v "\/\/" | grep -v "*"` The last 58 lines only use the fail without exception to get the failure details. I had used JUnit 5's assertThrows() in the tests instead of fail() or Assert.fail() in the 132 files. 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
[jira] [Commented] (FILEUPLOAD-303) Do not have dependency on javax.servlet
[
https://issues.apache.org/jira/browse/FILEUPLOAD-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114593#comment-17114593
]
Mohamed commented on FILEUPLOAD-303:
I think I've been misunderstood.
In other words in the *{{FileUploadBase}}* class there's two *deprecated*
methods *{{isMultipartContent}}* & *{{parseRequest}}* which they are dependent
to the {{javax.servlet}} by there parameters{{. }}Event If I use UploadContext
with FileUpload class I have to add the {{javax.servlet}} dependency because
{{FileUpload}} extends {{FileUploadBase}} with the two deprecated methods.{{}}
All I want is a new version of {{FileUploadBase *without* the two deprecated
methods. Hence I can use FileUpload without being forced to add dependecy to
}}{{javax.servlet (I'm not in a servlet based webapp).}}{{}}
> Do not have dependency on javax.servlet
> ---
>
> Key: FILEUPLOAD-303
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-303
> Project: Commons FileUpload
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Mohamed
>Priority: Major
>
> I'm trying to use FileUpload in my playframework projet to parse a
> multipart/mixed request. Every thing works well if I add the *javax.servlet*
> depency, which I do not use completely.
>
> I have created my own RequestContext like:
>
> {{public static class PlayRequestContext implements UploadContext {}}
> {{ private final Http.Request request;}}
> {{ private final ByteString bodyBuffer;}}
> {{ public PlayRequestContext(Http.Request request) {}}
> {{ this.request = request;}}
> {{ bodyBuffer = request.body().asBytes();}}
> {{ }}}
> {{ @Override}}
> {{ public String getCharacterEncoding() {}}
> {{ return StandardCharsets.ISO_8859_1.displayName();}}
> {{ }}}
> {{ @Override}}
> {{ public String getContentType() {}}
> {{ return
> request.getHeaders().get(Http.HeaderNames.CONTENT_TYPE).orElseThrow(unexpectedCase());}}
> {{ }}}
> {{ @Override}}
> {{ @Deprecated}}
> {{ public int getContentLength() {}}
> {{ return 0;}}
> {{ }}}
> {{ @Override}}
> {{ public InputStream getInputStream() {}}
> {{ return new ByteArrayInputStream(bodyBuffer.toArray());}}
> {{ }}}
> {{ @Override}}
> {{ public long contentLength() {}}
> {{ return bodyBuffer.length();}}
> {{ }}}
> {{}}}
>
> Is it possible to have another version without any dependecny to
> javax.servlet ?
>
> I thinks this is a great solution for every web application, not only servlet
> dependent projects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] coveralls edited a comment on pull request #159: Updated the fail() exceptions with Junit5.
coveralls edited a comment on pull request #159: URL: https://github.com/apache/commons-collections/pull/159#issuecomment-625612511 [](https://coveralls.io/builds/30983976) Coverage decreased (-0.004%) to 90.089% when pulling **b043d821d6c1b23784d9e7935146d5c40eab69f4 on dota17:junit5WithExceptions** into **9f37668d9243fc71178f0e94a2b560ef861a639a on apache:master**. 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
