You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Martin Petricek (JIRA)" <ji...@apache.org> on 2015/08/20 19:52:46 UTC
[jira] [Commented] (COMPRESS-321) Exception in
X7875_NewUnix.parseFromLocalFileData when parsing 0-sized "ux" local entry
[ https://issues.apache.org/jira/browse/COMPRESS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14705416#comment-14705416 ]
Martin Petricek commented on COMPRESS-321:
------------------------------------------
I forced compress to 1.10 in maven, retried the test and the result is the same (just some small differences in line numbers)
{code}
java.lang.ArrayIndexOutOfBoundsException: 13
at org.apache.commons.compress.archivers.zip.X7875_NewUnix.parseFromLocalFileData(X7875_NewUnix.java:199)
at org.apache.commons.compress.archivers.zip.X7875_NewUnix.parseFromCentralDirectoryData(X7875_NewUnix.java:220)
at org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:174)
at org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setCentralDirectoryExtra(ZipArchiveEntry.java:561)
at org.apache.commons.compress.archivers.zip.ZipFile.readCentralDirectoryEntry(ZipFile.java:616)
at org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:533)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:216)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:192)
at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:153)
at org.apache.tika.parser.pkg.ZipContainerDetector.detectZipFormat(ZipContainerDetector.java:141)
at org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:88)
at org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
at org.apache.tika.Tika.detect(Tika.java:155)
at org.apache.tika.Tika.detect(Tika.java:183)
at org.apache.tika.Tika.detect(Tika.java:223)
{code}
> Exception in X7875_NewUnix.parseFromLocalFileData when parsing 0-sized "ux" local entry
> ---------------------------------------------------------------------------------------
>
> Key: COMPRESS-321
> URL: https://issues.apache.org/jira/browse/COMPRESS-321
> Project: Commons Compress
> Issue Type: Bug
> Affects Versions: 1.9
> Reporter: Martin Petricek
>
> When trying to detect content type of a zip file with Tika 1.10 (which uses Commons Compress 1.9 internally) in manner like this:
> {code}
> byte[] content = ... // whole zip file.
> String name = "TR_01.ZIP";
> Tika tika = new Tika();
> return tika.detect(content, name);
> {code}
> it throws an exception:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 13
> at org.apache.commons.compress.archivers.zip.X7875_NewUnix.parseFromLocalFileData(X7875_NewUnix.java:199)
> at org.apache.commons.compress.archivers.zip.X7875_NewUnix.parseFromCentralDirectoryData(X7875_NewUnix.java:220)
> at org.apache.commons.compress.archivers.zip.ExtraFieldUtils.parse(ExtraFieldUtils.java:174)
> at org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setCentralDirectoryExtra(ZipArchiveEntry.java:476)
> at org.apache.commons.compress.archivers.zip.ZipFile.readCentralDirectoryEntry(ZipFile.java:575)
> at org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:492)
> at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:216)
> at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:192)
> at org.apache.commons.compress.archivers.zip.ZipFile.<init>(ZipFile.java:153)
> at org.apache.tika.parser.pkg.ZipContainerDetector.detectZipFormat(ZipContainerDetector.java:141)
> at org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:88)
> at org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> at org.apache.tika.Tika.detect(Tika.java:155)
> at org.apache.tika.Tika.detect(Tika.java:183)
> at org.apache.tika.Tika.detect(Tika.java:223)
> {code}
> The zip file does contain two .jpg images and is not a "special" (JAR, Openoffice, ... ) zip file.
> Unfortunately, the contents of the zip file is confidential and so I cannot attach it to this ticket as it is, although I can provide the parameters supplied to
> org.apache.commons.compress.archivers.zip.X7875_NewUnix.parseFromLocalFileData(X7875_NewUnix.java:199) as caught by the debugger:
> {code}
> data = {byte[13]@2103}
> 0 = 85
> 1 = 84
> 2 = 5
> 3 = 0
> 4 = 7
> 5 = -112
> 6 = -108
> 7 = 51
> 8 = 85
> 9 = 117
> 10 = 120
> 11 = 0
> 12 = 0
> offset = 13
> length = 0
> {code}
> This data comes from the local zip entry for the first file, it seems the method tries to read more bytes than is actually available in the buffer.
> It seems that first 9 bytes of the buffer are 'UT' extended field with timestamp, followed by 0-sized 'ux' field (bytes 9-12) that is supposed to contain UID/GID - according to infozip's doc the 0-size is common for global dictionary, but the local dictionary should contain complete data. In this case for some reason it does contain 0-sized data.
> Note that 7zip and unzip can unzip the file without even a warning, so Commons Compress should be also able to handle that file correctly without choking on that exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)