[
https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Shattu updated COMPRESS-384:
----------------------------------
Yep, i'm doing something slightly novel, but I would expect to still be
supported by the library.
so given something like
ArchiveInputStream archiveStream = new
ArchiveStreamFactory().createArchiveInputStream(format, stream);
The stream I pass into the factory is not just a straightforward
FileInputStream, but a FileInputStream that is wrapped using a
FilterInputStream, which deliberately blocks if there is no more data.
The reason I do this, is that I might have a separate slow running
process generating the tar file and the processing reading the tar file
doesn't know when it had ended. Perhaps there is a better way to do this
so please advise.
In any case, this approach works nicely with Zip Archives but not with
Tar file.
Does that make sense?
Thanks,
Jason
> 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)
