Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 26 Apr 2017 17:53:04 +0000 (UTC)
From: "Stefan Bodewig (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13062746.1491772344000.58073.1493229184296@Atlassian.JIRA>
In-Reply-To: <JIRA.13062746.1491772344000@Atlassian.JIRA>
References: <JIRA.13062746.1491772344000@Atlassian.JIRA> <JIRA.13062746.1491772344516@jira-lw-us.apache.org>
Subject: [jira] [Resolved] (COMPRESS-384) Tar File EOF not being detected
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 26 Apr 2017 17:53:09 -0000


     [ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Bodewig resolved COMPRESS-384.
-------------------------------------
    Resolution: Not A Bug

I'm sorry, but I'm afraid there is no way to do things as you need them without sacrificing compatibility with some of the many dialects.

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