commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [compress] close() and archives/streams in an invalid state
Date Mon, 15 Aug 2011 12:25:24 GMT
On 15 August 2011 09:56, Stefan Bodewig <bodewig@apache.org> wrote:
> Hi,
>
> while working on the Zip64 stuff I deliberately created some invalid
> archives to test I get the expected exceptions.  While doing so I
> realized I couldn't close the underlying stream because
> ZipArchiveOutputStream's close would throw an exception as finish()
> failed before ever closing the wrapped stream.  The calling code may not
> even have a handle to the underlying stream if it used the File-arg
> constructor and so in the end a broken archive leaks the file
> descriptor.
>
> Then I went looking through the other implementations and found we are
> consistent here as far as archivers and bzip2 go.  All of them will not
> close the underlying stream if the archive/stream is invalid.  I'm not
> sure what gzip does as it just delegates to close in the Java classlib's
> GZipOutputStream.
>
> I wonder whether we should rather change the behavior to always close
> the underlying stream or whether we should add a new method - I called
> in destroy in ZipArchiveOutputStream - that does so.
>
> Or maybe we just document it for 1.3, add destroy as a non-common method
> where needed (like in ZIP, in all other cases the user code should have
> access to the underlying stream) - and revisit this in the 2.x
> timeframe, even though I can't see what could be broken by always
> closing the stream in a finally block.
>
> Does anybody see a good reason why the close behavior should stay the
> way it is right now?

For output, it seems sensible to close the underlying stream on
failure, as the content is likely to be garbage.

For input, there might be a use case for leaving the stream open, in
case some kind of recovery is possible.
It would be useful to have a way of determining the input file pointer
at the point of failure.

> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message