[
https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980046#comment-15980046
]
Stefan Bodewig commented on COMPRESS-384:
-----------------------------------------
Yes, I'm afraid what you are doing won't work for general formats.
For tar it should signal EOF after it has read two consecutive 512 byte blocks
of zeros after an entry has been finished, but not all tar archivers create
these blocks. Looking at you archive I see a lot of trailing zeros, so there
maybe something strange going on here, I'll look into it.
> 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)
