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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

ASF GitHub Bot (Jira)
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
            Assignee: Stefan Bodewig


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

       
Reply | Threaded
Open this post in threaded view
|

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

ASF GitHub Bot (Jira)

     [ https://issues.apache.org/jira/browse/COMPRESS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Bodewig updated COMPRESS-153:
------------------------------------

    Fix Version/s: 2.0
         Assignee:     (was: Stefan Bodewig)

> 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

       
Reply | Threaded
Open this post in threaded view
|

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

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ 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

       
Reply | Threaded
Open this post in threaded view
|

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

ASF GitHub Bot (Jira)
In reply to this post by ASF GitHub Bot (Jira)

    [ 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