[
https://issues.apache.org/jira/browse/COMPRESS-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178850#comment-17178850
]
Peter Lee commented on COMPRESS-549:
------------------------------------
Hi [~sebkur]
I think there are some problems in your testData. The variable
_general_purpose_bit_flag_bit3_on_ seems to be used to indicate if Data
Descriptor is used or not. (you set it to be true in your test cases) But it
seems the test data lack of Data Descriptor. I modified the data a little bit
and it is passed.
{code:java}
public static byte[] get(boolean general_purpose_bit_flag_bit3_on)
{
final byte gpbf = (byte) (general_purpose_bit_flag_bit3_on ? 0x08
: 0x00);
return new byte[] {
// Local File header
'P', 'K', 3, 4, // Local File Header Signature
13, 0, // Version needed to extract
gpbf, 8, // General purpose bit flag
ZipEntry.STORED, 0, // Compression method
'q', 'l', 't', 'G', // Last Modification time & date
0, 0, 0, 0, // CRC32
0, 0, 0, 0, // Compressed Size
0, 0, 0, 0, // Uncompressed Size
12, 0, // File name length
0, 0, // Extra field length
'F', 'o', 'l', 'd', 'e', 'r', '_', 'n', 'a', 'm', 'e', '/',
/********************************/
// Data Descriptor, this sector should not appear if
general_purpose_bit_flag_bit3_on is false
'P', 'K', 7, 8, // Data Descriptor signature
0, 0, 0, 0, // CRC32 in Data Descriptor
0, 0, 0, 0, // compressed size in Data Descriptor
0, 0, 0, 0, // uncompressed size Data Descriptor
/********************************/
// File name
// Central directory file header
'P', 'K', 1, 2, // Central Directory File Header Signature
13, 0, // Version made by
13, 0, // Version needed to extract
gpbf, 8, // General purpose bit flag
ZipEntry.STORED, 0, // Compression method
'q', 'l', 't', 'G', // Last Modification time & date
0, 0, 0, 0, // CRC32
0, 0, 0, 0, // Compressed Size
0, 0, 0, 0, // Uncompressed Size
12, 0, // File name length
0, 0, // Extra field length
0, 0, // File comment length
0, 0, // Disk number where file starts
0, 0, // Internal File attributes
0, 0, 0, 0, // External File attributes
0, 0, 0, 0, // Relative offset of local header file
'F', 'o', 'l', 'd', 'e', 'r', '_', 'n', 'a', 'm', 'e', '/',
// File name
// End of Central Directory Record
'P', 'K', 5, 6, // Local File Header Signature
0, 0, // Number of this disk
0, 0, // Disk where CD starts
1, 0, // Number of CD records on this disk
1, 0, // Total number of records
58, 0, 0, 0, // Size of CD
42, 0, 0, 0, // Offset of start of CD
0, 0, // Comment length
};
}
{code}
Please note the data I added between Local File Header and Central Directory
file.
> Inconsistency with latest PKZip standard
> ----------------------------------------
>
> Key: COMPRESS-549
> URL: https://issues.apache.org/jira/browse/COMPRESS-549
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.20
> Reporter: Sebastian Kürten
> Priority: Major
>
> I came across some Zip archives that cannot be read using
> ZipArchiveInputStream. Investigating the issue, I found that
> java.util.zip.ZipInputStream from the JDK shows the same behavior while
> java.util.zip.ZipFile seems to do fine. For java.util.zip.ZipInputStream, the
> issue has been reported here:
> [https://bugs.openjdk.java.net/browse/JDK-8143613] and an example file is
> provided. I copied the testing file into a repository for testing. Here's the
> example file:
> [https://github.com/sebkur/test-zip-impls/blob/master/src/test/java/de/topobyte/zip/tests/jdk8143613/TestData.java]
> and the test that fails reading that data using ZipArchiveInputStream:
> [https://github.com/sebkur/test-zip-impls/blob/master/src/test/java/de/topobyte/zip/tests/jdk8143613/TestCommonsZipInputStream.java]
>
>
> If this file is indeed a ZIP archive consistent with the PKZip spec, I think
> commons-compress does not work according to the spec. I would appreciate if
> someone could look into this and verify if this is indeed a bug in
> commons-compress. Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
