commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-384) Tar File EOF not being detected
Date Sun, 23 Apr 2017 08:49:04 GMT

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

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

I still need to look into why the tar stream doesn't detect EOF, but want to share an idea,
Jason. While most archiving formats haven't got any way of knowing when the stream is finished,
most compression formats do. gzip, xz, bzip2 all know when the compressed stream is finished,
so if you can make your archive creator produce a tar.gz rather than a tar you should be able
to work around the problem - at the cost of higher processing time on both sides.

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

Mime
View raw message