commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IO-497) DeferredFileOutputStream produces unhandled IOExceptions if the java.io.tmpdir is deleted
Date Fri, 22 Jan 2016 09:09:39 GMT

    [ https://issues.apache.org/jira/browse/IO-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15112128#comment-15112128
] 

Sebb commented on IO-497:
-------------------------

bq. One approach produces a FileNotFoundException while the other produces a plain IOException.

These are both IOExceptions, so that does not seem unreasonable.

As to the behaviour of CentOS - I understand why it might delete old files from the temporary
directory, but it does not seem reasonable to delete the directory entirely.
Surely that will cause problems for lots of applications, not just the IO class? What happens
when the next app wants to create a temporary file?

Note: assuming that CentOS does not delete the temporary directory if it contains any active
files, a work-round for your case might be to have a background task which updates a dummy
file in the temporary directory.

> DeferredFileOutputStream produces unhandled IOExceptions if the java.io.tmpdir is deleted
> -----------------------------------------------------------------------------------------
>
>                 Key: IO-497
>                 URL: https://issues.apache.org/jira/browse/IO-497
>             Project: Commons IO
>          Issue Type: Bug
>          Components: Streams/Writers
>    Affects Versions: 2.4
>         Environment: unix-like operating systems where temporary disk storage is routinely
purged; CentOS specifically
>            Reporter: Nicholas Byrd
>         Attachments: dfos-bug.tar.gz
>
>
> In the event that the Java temporary directory is deleted prior to the DeferredFileOutputStream
trying to use it, the stream will throw one of two different IOExceptions (depending on how
the Stream was constructed). 
> This may sound like an unrealistic use-case at first, but it is legitimate as one of
my company's applications encountered it after the underlying operating system (CentOS) automatically
purged the contents of its tmp directory. (The application uses Commons FileUpload, which
invokes DeferredFileOutputStream and does not handle the error itself.) Our current work-around
is to restart the server when this happens, but we feel that the underlying library should
perhaps be intelligent enough to recover from such an error.
> Additionally, it seems an awkward experience that two different errors are produced based
on how the stream was constructed. One approach produces a FileNotFoundException while the
other produces a plain IOException. 
> A small maven project containing a single JUnit test that highlights the error will be
attached (see [dfos-bug.tar.gz|https://issues.apache.org/jira/secure/attachment/12783728/dfos-bug.tar.gz]).




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message