commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-202) Document EOF behavior of TarArchiveInputStream
Date Sat, 29 Dec 2012 11:32:13 GMT


Stefan Bodewig commented on COMPRESS-202:

The same issue hits ZipArchiveInputStream as it stops as soon as it hits the central directory
leaving everything starting from there unconsumed.

It might be best to add a new method to both streams that would consume the remainder of the
archive on demand - and document that there may be data left in the stream if you don't call
this method at the same time.
> Document EOF behavior of TarArchiveInputStream
> ----------------------------------------------
>                 Key: COMPRESS-202
>                 URL:
>             Project: Commons Compress
>          Issue Type: Wish
>          Components: Documentation
>            Reporter: Paul Burrowes
>            Priority: Minor
> When reading from a tar stream getNextEntry() returns null to signify EOF after reading
the first EOF record. This leaves the second EOF record in the stream unread potentially confusing
subsequent readers or blocking the writer trying to flush the stream in a piped configuration
e.g. network streaming.
> The solution to this is to, if you care about subsequent data or true EOF, read from
the underlying InputStream until EOF or a protocol record marker.
> It would be nice to have the documentation of TarArchiveInputStream mention that it does
not read the stream fully but stops at the first EOF record.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message