Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 27 Apr 2014 15:40:15 +0000 (UTC)
From: "Stefan Bodewig (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12710698.1398475822135.188658.1398613215073@arcas>
In-Reply-To: <JIRA.12710698.1398475822135@arcas>
References: <JIRA.12710698.1398475822135@arcas>
Subject: [jira] [Commented] (COMPRESS-280) [COMPRESS] Change TarInputStream
 Skip Behavior
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Stefan Bodewig commented on COMPRESS-280:
-----------------------------------------

[your patch still calls IOUtils.skip inside the skip method, I assume you meant to call is.skip(Math.min(n, available)) instead.]

It is certainly true TarArchiveInputStream#skip is doing more than it needs to, but does this cause any harm?

> [COMPRESS] Change TarInputStream Skip Behavior
> ----------------------------------------------
>
>                 Key: COMPRESS-280
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-280
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Archivers
>    Affects Versions: 1.8
>            Reporter: BELUGA BEHR
>            Priority: Minor
>             Fix For: 1.9
>
>         Attachments: TarArchiveInputStream.java.patch
>
>
> InputStream#skip declares:
> {quote}
> Skips over and discards n bytes of data from this input stream. The skip method may, for a variety of reasons, end up skipping over some smaller number of bytes, possibly 0.  This may result from any of a number of conditions; reaching end of file before n bytes have been skipped is only one possibility. The actual number of bytes skipped is returned.  If n is negative, no bytes are skipped.
> {quote}
> I would recommend doing away with the call to the local IOUtils in the Stream's skip method and just call skip directly on the underlying stream.  I'd also amend the JavaDoc to say "end up skipping .. some smaller number of bytes... reaching the end of the current entry."  The stream is not required to make any best-effort.  For your example, there should be a BufferedInputStream between the TarInputStream and the CipherInputStream.  This would put it more in line with all other InputStreams.
> If a client wants to skip an entry manually, they would have to call Commons-IO IOUtils#skipFully, IOUtils#skip, etc.
> You would then have to modify getNextTarEntry() to call the IOUtils#skip method.


--
This message was sent by Atlassian JIRA
(v6.2#6252)