[
https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980334#comment-15980334
]
Stefan Bodewig commented on COMPRESS-384:
-----------------------------------------
Oh my, tar dialects. Here is the full story.
Tar archive consist of records (512 bytes each) grouped in blocks (usually 20
records, i.e. 10kB). The end of the tar archive is signalled by two consecutive
records of zeros, your archive has such a trailer and {{TarArchiveInputStream}}
detects it. But your archive ends after those two records while
{{TarArchiveInputStream}} tries to finish reading the current block (there are
still > 3500 bytes missing for the first block). So 7z uses one of the dialects
that don't pad out the last block but {{TarArchiveInputStream}} has to try to
consume it and thus still tries to read when your archive is done.
I'm afraid there isn't anything we can do about it. See my suggestion from
about half an hour ago for a workaround.
> 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)
