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

Nicholas Byrd commented on IO-497:
----------------------------------

Thanks for the update, [~ralfhauser]. I've retried the attached unit tests 
using the latest commons-io 2.6-SNAPSHOT build. The "testStreamWithDelete" test 
now passes, but the "testStreamWithDeleteAlternative" test still fails. So it 
would seem that IO-512 is potentially only a partial fix at this point. 

> 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, dfos-bug-v2.tar.gz, example_stack.txt
>
>
> 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.4.14#64029)

Reply via email to