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)