commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [compress] not reading archive stream completely
Date Thu, 17 Jan 2013 13:11:43 GMT
Late reply but anyway.

If we see `getNextEntry` return null we should position the stream at the
end of the archive.
I think that's your (1). Sounds simpler and more straight forward from an
IIUC that reading should only be a few bytes. A second EOF marker for TAR
for example.

Did I get that right?

My 2 cents

On Thu, Jan 3, 2013 at 5:22 PM, Stefan Bodewig <> wrote:

> Hi all,
> COMPRESS-202 and COMPRESS-206 only talk about TAR but something similar
> aplies at least to ZIP as well: once we detect that an archive doesn't
> contain any more entries, we stop reading the input stream, even if it
> contains more stuff that is part of the archive.  This causes problems
> for use cases where the stream holds interesting data behind the
> archive.
> I'm a bit torn between two approaches - and it is quite possible I'm
> overlooking even more alternatives.
> (1) As soon as we detect there are no more entries, we immediately read
> the remainder and consume all of the stream that made up the archive.
> At least for ZIP and TAR this is possible as getNextEntry "knows" when
> it has seen the last entry.
> (2) Add additional "readRemainderOfArchive() throws IOException" method
> in ArchiveInputStream (or just those of the affected formats) that could
> be invoked any time and consume as much of the stream as belongs to the
> archive.
> Alternative (1) is somewhat breaking backwards compatibility - but only
> for some contrieved cases AFAICT.  Alternative (2) would be useful in a
> case where the user isn't interested in the rest of an archive's content
> after finding an entry but wants to consume it completely.
> I realize the two alternative could be implemented at the same time
> where the most naive implementation of readRemainderOfArchive simply
> reads entries until getNextEntry returns null.
> Any thoughts?
>     Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message