[jira] [Commented] (COMPRESS-153) close() in several OutputStream implementations doesn't close the underlying stream if the archive would be corrupt

["Stefan Bodewig (JIRA)" <ji...@apache.org>]

    [ 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