[
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
