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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
