commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-153) close() in several OutputStream implementations doesn't close the underlying stream if the archive would be corrupt
Date Fri, 19 Aug 2011 09:48:27 GMT

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

Stefan Bodewig commented on COMPRESS-153:
-----------------------------------------

It turns out ArchiveOutputStreamTest#testCallSequence*() explicitly checks one can call closeArchiveEntry
after a failed call to close (line 176 in svn revision 1157880), i.e. one can recover from
a failed close.

I find this dubious at best but since it obviously break the current contract as stated in
the tests I've pushed it to the "rethink for 2.0" list of issues.

> close() in several OutputStream implementations doesn't close the underlying stream if
the archive would be corrupt
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: COMPRESS-153
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-153
>             Project: Commons Compress
>          Issue Type: Bug
>            Reporter: Stefan Bodewig
>             Fix For: 2.0
>
>
> In some cases like when ZiparchiveOutputStream's File-arg constructor is used, the user
code doesn't even have any chance to close the underlying stream, even if it would catch the
exception from close() and then close the wrapped stream by itself.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message