[
https://issues.apache.org/jira/browse/TIKA-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224762#comment-15224762
]
Hudson commented on TIKA-1929:
------------------------------
SUCCESS: Integrated in tika-2.x #73 (See
[https://builds.apache.org/job/tika-2.x/73/])
TIKA-1929 -- ensure deletion of temp file no matter which type of (tallison:
rev 77c1dd3ab2c0bf93568703c02b4dc3453cde7c82)
*
tika-parser-modules/tika-parser-database-module/src/main/java/org/apache/tika/parser/jdbc/SQLite3Parser.java
*
tika-parser-modules/tika-parser-database-module/src/main/java/org/apache/tika/parser/jdbc/AbstractDBParser.java
*
tika-parser-modules/tika-parser-database-module/src/main/java/org/apache/tika/parser/jdbc/SQLite3DBParser.java
*
tika-parser-modules/tika-parser-database-module/src/test/java/org/apache/tika/parser/jdbc/SQLite3ParserTest.java
> Need to close resources on exception in sqlite parser
> -----------------------------------------------------
>
> Key: TIKA-1929
> URL: https://issues.apache.org/jira/browse/TIKA-1929
> Project: Tika
> Issue Type: Bug
> Reporter: Tim Allison
> Priority: Minor
>
> If there's an exception during parsing of a SQLite file, we aren't
> guaranteeing that the temp file is deleted.
> If a TikaInputStream is used, we assume the calling code will close the
> stream and thereby delete the temp file. However, if another type of
> InputStream is used, we copy that to a temp file, and we need to ensure that
> we delete that temp file if there's an exception during the parse.
> While we're at it, we should also clean up test code to close streams
> correctly.
> Unrelated to this issue... I noticed that xerial's SQLite code is still
> leaving behind a copy of the native dll in the temp folder on Windows the
> first time the SQLite parser is called. See
> https://github.com/xerial/sqlite-jdbc/issues/80.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
