[jira] [Commented] (COMPRESS-202) Document EOF behavior of TarArchiveInputStream

["Stefan Bodewig (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540863#comment-13540863 ] 

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: https://issues.apache.org/jira/browse/COMPRESS-202
>             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: http://www.atlassian.com/software/jira