[
https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979965#comment-15979965
]
Stefan Bodewig commented on COMPRESS-384:
-----------------------------------------
Maybe I'm starting to understand.
So your FilterInputStream blocks on read if the underlying stream doesn't
provide any data right now. What are you expecting the underlying stream to do,
i.e. when are you blocking and when do you assume the stream has been exhausted
and return -1 from read in the implementation of your own?
> Tar File EOF not being detected
> -------------------------------
>
> Key: COMPRESS-384
> URL: https://issues.apache.org/jira/browse/COMPRESS-384
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.13
> Environment: Windows 10, JDK 1.8
> Reporter: Jason Shattu
> Attachments: file.tar
>
>
> I've created both a zip and tar file, with the same contents using the latest
> version of 7zip. When I read both archives using code of the form:
> ArchiveStreamFactory().createArchiveInputStream(format, inputStream);
> I notice that both formats correctly list their contents, however the Tar
> Input doesn't return a "null" entry when it hits the EOF from
> archiveStream.getNextEntry()
> this makes it hard to distinguish between a genuine EOF or a file which is
> still being written to.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
