You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Hudson (Jira)" <ji...@apache.org> on 2020/03/06 21:18:00 UTC

[jira] [Commented] (TIKA-3061) Streaming zip container detector stopping short

    [ https://issues.apache.org/jira/browse/TIKA-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053757#comment-17053757 ] 

Hudson commented on TIKA-3061:
------------------------------

SUCCESS: Integrated in Jenkins build Tika-trunk #1786 (See [https://builds.apache.org/job/Tika-trunk/1786/])
TIKA-3061 -- need to read inputstream completely before processing in (tallison: [https://github.com/apache/tika/commit/9cb838227a020744e27c0b5adbbd1652c8f2dda1])
* (edit) tika-core/src/test/java/org/apache/tika/TikaTest.java
* (edit) tika-parsers/src/test/java/org/apache/tika/detect/TestContainerAwareDetector.java
* (add) tika-parsers/src/test/resources/test-documents/testOpenOfficeInAZip.zip
* (edit) tika-parsers/src/main/java/org/apache/tika/parser/pkg/StreamingZipContainerDetector.java


> Streaming zip container detector stopping short
> -----------------------------------------------
>
>                 Key: TIKA-3061
>                 URL: https://issues.apache.org/jira/browse/TIKA-3061
>             Project: Tika
>          Issue Type: Task
>            Reporter: Tim Allison
>            Priority: Major
>
> In the recent regression runs in prep for 1.24, I found that in a few cases, an open office document inside of a zip was no longer identified as an open office document, but rather another zip file.
> For an unknown reason, the new {{detectStarOfficeX}} is doing something to the ziparchiveinputstream that is causing it to silently fail to iterate through all of the entries in the zip file...or, in short, causing it to stop short.  If we copy the bytes to a byte array and then process them, all is well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)