[ https://issues.apache.org/jira/browse/TIKA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824895#comment-16824895 ]
Boris Petrov commented on TIKA-2849: ------------------------------------ [~talli...@apache.org] I see now, thanks. By "parsing" you mean text-extraction, correct? The funny thing is that we have our own abstraction of a File (which could be a local file, a network one or just a stream in memory) and we use Tika by *always* passing a stream we get from this File of ours. And we have our own method of converting this File to a local file (which is smart and doesn't make a copy if this is already a local file). But now I see that Tika actually prefers in some places a file to be passed instead of a stream (which, by the way, I haven't read anywhere in the documentation so you might want to improve that a bit so others are not bitten like me) but that doesn't very well match our own File abstraction. So a question I would ask now is is it possible, when calling {{Tika.parse}} or {{Tika.detect}}, to *know* whether it/a detector will need to spool to a file so that we can use our own mechanism for that and not pass it a stream but rather a file? > 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)