[
https://issues.apache.org/jira/browse/TIKA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813500#comment-16813500
]
Boris Petrov commented on TIKA-2849:
------------------------------------
Hi,
First thing:
{noformat}
TikaInputStream.getPath() line: 588
TikaInputStream.getFile() line: 616
ZipContainerDetector.detectOPCBased(TikaInputStream) line: 241
ZipContainerDetector.detectZipFormat(TikaInputStream) line: 173
ZipContainerDetector.detect(InputStream, Metadata) line: 110
DefaultDetector(CompositeDetector).detect(InputStream, Metadata) line: 84
Tika.detect(InputStream, Metadata) line: 156
Tika.detect(InputStream, String) line: 184
... my code
{noformat}
Second thing - yes, sorry, I just think this is an obvious bug, that's why I
directly opened an issue. Will know for next time!
Final thing - if some parsers require a local file and Tika is passed an
InputStream (and not an explicit file or path) then it should definitely *not*
use those parsers as, again, copying a file locally could be horribly
expensive. This happens on any kind of data - an Excel file was the first file
that I saw it happening on.
> TikaInputStream copies the input stream locally
> -----------------------------------------------
>
> Key: TIKA-2849
> URL: https://issues.apache.org/jira/browse/TIKA-2849
> Project: Tika
> Issue Type: Bug
> Affects Versions: 1.20
> Reporter: Boris Petrov
> Priority: Major
>
> When doing "tika.detect(stream, name)" and the stream is a "TikaInputStream",
> execution gets to "TikaInputStream#getPath" which does a "Files.copy(in,
> path, REPLACE_EXISTING);" which is very, very bad. This input stream could
> be, as in our case, an input stream from a network file which is tens or
> hundreds of gigabytes large. Copying it locally is a huge waste of resources
> to say the least. Why does it do that and can I make it not do it? Or is this
> something that has to be fixed in Tika?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
