[
https://issues.apache.org/jira/browse/COMPRESS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087624#comment-13087624
]
Stefan Bodewig edited comment on COMPRESS-153 at 8/19/11 9:48 AM:
------------------------------------------------------------------
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 breaks the current contract
as stated in the tests I've pushed this issue to the "rethink for 2.0" list of
issues.
was (Author: bodewig):
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
