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

Stefan Bodewig commented on COMPRESS-384:
-----------------------------------------

You are correct, tar and zip deal with EOF differently as zip has an internal 
structure that signals the end of the readable content while tar simply has to 
read until it hits EOF. Many archivers won't know when the archive is finished 
until they hit EOF, cpio or ar are in the same boat. 7zip on the other hand has 
a structure that allows it to know the archive is finished as well. What zip 
and 7zip share is some kind of table of contents stored internally while tar 
and others really are just a stream of consecutive entries without any relation 
to each other and they only know they are done when there is no next entry.

I think I had it backwards at first, sorry. So your FilterInputStream is the 
one TarArchiveInputStream is reading from, right? Then you use getNextEntry to 
read entries from the tar stream wrapping your blocking stream.

What exactly happens that you didn't expect? I'm sorry if I sound stupid, but 
it still isn't clear to me.

> 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)

Reply via email to