[
https://issues.apache.org/jira/browse/TIKA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16822209#comment-16822209
]
Tim Allison commented on TIKA-2849:
-----------------------------------
[~boris-petrov] let me know if I closed this prematurely. If there's an
underlying file in TikaInputStream _or_ if the user sets {{markLimit}} to -1,
we'll use the underlying file (e.g. TikaInputStream.get(File f)) or spool to
disk and detect on the full file. If {{markLimit}} > 0 but there's an
underlying file, we'll do file based detection.
We're currently doing streaming detection if a user sends in a non
TikaInputStream or if the TikaInputStream wraps an InputStream (not a file).
There are a number of improvements I'd like to make to zip detection, and I
think we'll eventually move towards streaming detection as default, but I don't
want to make such a drastic change yet.
Let us know if we should reopen this.
> 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
> Assignee: Tim Allison
> Priority: Major
> Fix For: 1.21
>
>
> 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)
