tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Allison (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (TIKA-1929) Need to close resources on exception in sqlite parser
Date Mon, 04 Apr 2016 17:59:26 GMT

     [ https://issues.apache.org/jira/browse/TIKA-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tim Allison updated TIKA-1929:
------------------------------
    Description: 
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.

  was:If there's an exception during parsing of a SQLite file, we aren't guaranteeing that
the temp file is deleted.


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

Mime
View raw message