You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Mike Scholl (JIRA)" <ji...@apache.org> on 2018/05/29 15:45:00 UTC
[jira] [Created] (COMPRESS-454) Bug in determination of Signature
for STORED ZipArchive with data descriptor
Mike Scholl created COMPRESS-454:
------------------------------------
Summary: Bug in determination of Signature for STORED ZipArchive with data descriptor
Key: COMPRESS-454
URL: https://issues.apache.org/jira/browse/COMPRESS-454
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.16.1
Environment: Windows, JDK 9.0.4
Reporter: Mike Scholl
The archive file contains a data descriptor, which is not recognized and lead to "
{code:java}
java.util.zip.ZipException: Unexpected record signature: 0X302D3831{code}
The process to check if one block contains a signature(ZipArchiveInputStream -> bufferContainsSignature) seems to be a little buggy.
The following block is processed when the exception comes up, for the file.
[13, 10, 60, 73, 66, 65, 78, 62, 65, 84, 52, 48, 54, 48, 48, 48, 48, 48, 48, 48, 48, 55, 53, 48, 48, 48, 53, 51, 60, 47, 73, 66, 65, 78, 62, 13, 10, 60, 47, 73, 100, 62, 13, 10, 60, 47, 67, 100, 116, 114, 65, 99, 99, 116, 62, 13, 10, 60, 47, 82, 108, 116, 100, 80, 116, 105, 101, 115, 62, 13, 10, 60, 82, 108, 116, 100, 65, 103, 116, 115, 62, 13, 10, 60, 68, 98, 116, 114, 65, 103, 116, 62, 13, 10, 60, 70, 105, 110, 73, 110, 115, 116, 110, 73, 100, 62, 13, 10, 60, 66, 73, 67, 62, 66, 65, 87, 65, 65, 84, 87, 87, 88, 88, 88, 60, 47, 66, 73, 67, 62, 13, 10, 60, 47, 70, 105, 110, 73, 110, 115, 116, 110, 73, 100, 62, 13, 10, 60, 47, 68, 98, 116, 114, 65, 103, 116, 62, 13, 10, 60, 67, 100, 116, 114, 65, 103, 116, 62, 13, 10, 60, 70, 105, 110, 73, 110, 115, 116, 110, 73, 100, 62, 13, 10, 60, 66, 73, 67, 62, 66, 65, 87, 65, 65, 84, 87, 87, 88, 88, 88, 60, 47, 66, 73, 67, 62, 13, 10, 60, 47, 70, 105, 110, 73, 110, 115, 116, 110, 73, 100, 62, 13, 10, 60, 47, 67, 100, 116, 114, 65, 103, 116, 62, 13, 10, 60, 47, 82, 108, 116, 100, 65, 103, 116, 115, 62, 13, 10, 60, 80, 117, 114, 112, 62, 13, 10, 60, 67, 100, 62, 79, 84, 72, 82, 60, 47, 67, 100, 62, 13, 10, 60, 47, 80, 117, 114, 112, 62, 13, 10, 60, 82, 109, 116, 73, 110, 102, 62, 13, 10, 60, 83, 116, 114, 100, 62, 13, 10, 60, 67, 100, 116, 114, 82, 101, 102, 73, 110, 102, 62, 13, 10, 60, 84, 112, 62, 13, 10, 60, 67, 100, 79, 114, 80, 114, 116, 114, 121, 62, 13, 10, 60, 67, 100, 62, 83, 67, 79, 82, 60, 47, 67, 100, 62, 13, 10, 60, 47, 67, 100, 79, 114, 80, 114, 116, 114, 121, 62, 13, 10, 60, 47, 84, 112, 62, 13, 10, 60, 82, 101, 102, 62, 53, 48, 49, 48, 54, 52, 55, 52, 49, 52, 60, 47, 82, 101, 102, 62, 13, 10, 60, 47, 67, 100, 116, 114, 82, 101, 102, 73, 110, 102, 62, 13, 10, 60, 47, 83, 116, 114, 100, 62, 13, 10, 60, 47, 82, 109, 116, 73, 110, 102, 62, 13, 10, 60, 47, 84, 120, 68, 116, 108, 115, 62, 13, 10, 60, 47, 78, 116, 114, 121, 68, 116, 108, 115, 62, 13, 10, 60, 47, 78, 116, 114, 121, 62, 13, 10, 60, 47, 83, 116, 109, 116, 62, 13, 10, 60, 47, 66, 107, 84, 111, 67, 115, 116, 109, 114, 83, 116, 109, 116, 62, 13, 10, 60, 47, 68, 111, 99, 117, 109, 101, 110, 116, 62, 80, 75, 7, 8, -70, -19, -86, -114, -92, 11, 0, 0, -92, 11, 0, 0]
The lastRead variable is set to 497. The offset is 15.
The *for* in *bufferContainsSignature* do not recognize the data descriptor because it goes only to the *lastRead - 4*.
In the following method *cacheBytesRead* only 15 bytes from 497 to 512 are cached, so the P((byte)80) on position 496 is not cached in the next block.
My suggestion for the solution is to check all bytes(*buf.array().length - 4*) in ZipArchiveInputStream -> bufferContainsSignature, if they contain the ZipArchiveInputStream.LFH, ZipArchiveInputStream.CFH or ZipArchiveInputStream.DD bytes, but maybe I miss something.
However, seems to work for the example files.
Sorry not to share the example files they are created by a customer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)