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 API POV. 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 -- Torsten On Thu, Jan 3, 2013 at 5:22 PM, Stefan Bodewig <bode...@apache.org> 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
