[
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)
