[
https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15964304#comment-15964304
]
Stefan Bodewig commented on COMPRESS-384:
-----------------------------------------
Thanks for the report Jason
you are absolutely right when you expect {{TarArchiveInputStream}} to return
{{null}} on {{getNextEntry}} - this is the contract of the method - and in
general it does. At least in our tests. What does it do instead in your case?
Throw an exception?
Unfortunately the tar format is not really a format as much as a collection of
dialects built on top of a format. Tar archives are supposed to end in two
512byte block of 0s, but this is not always true. Maybe the archive you've
created uses some variation we're not prepared for. Can you attach an example
archive that doesn't contain any sensitive data and exhibits the problem?
> 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
>
> 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)
