[jira] [Resolved] (COMPRESS-321) Exception in X7875_NewUnix.parseFromLocalFileData when parsing 0-sized "ux" local entry

["Stefan Bodewig (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/COMPRESS-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Bodewig resolved COMPRESS-321.
-------------------------------------
    Resolution: Fixed

Thanks, Martin

> 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, 1.10
>            Reporter: Martin Petricek
>            Assignee: Stefan Bodewig
>             Fix For: 1.11
>
>
> 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)