commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BELUGA BEHR (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (COMPRESS-277) IOUtils.skip does not work as advertised
Date Sat, 26 Apr 2014 14:51:20 GMT

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

BELUGA BEHR updated COMPRESS-277:
---------------------------------

    Comment: was deleted

(was: Stefan, Fabian,

Please see my patch.  I still maintain that it is the correct implementation.  I think we
needs to keep the functionality geared for the generic case and keep as closely to the expected
InputStream behavior as possible. 

"consumeRemainderOfLastBlock" - The "last block" is so small, hardly a factor in this case.
 Chances are, the block of the Cipher will contain this "remainder" as the "remainder" is,
on average, 256 bytes.

How do you modify getNextTarEntry?

{code:title=Pseudo.java|borderStyle=solid}

CipherInputStream cis = new CipherInputStream ()
TarInputStream tis = new TarInputStream(cis);

while (tis.getNextEntry() != null)
{
    // IO-Commons
    IOUtils.skip(tis, Long.MAX_VALUE);
}

{code})

> IOUtils.skip does not work as advertised
> ----------------------------------------
>
>                 Key: COMPRESS-277
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-277
>             Project: Commons Compress
>          Issue Type: Bug
>    Affects Versions: 1.8
>            Reporter: Fabian Lange
>             Fix For: 1.9
>
>
> I am trying to feed a TarInputStream from a CipherInputStream.
> It does not work, because IOUtils.skip() does not adhere to the contract it claims in
javadoc:
> "     * <p>This method will only skip less than the requested number of
>      * bytes if the end of the input stream has been reached.</p>"
> However it does:
>             long skipped = input.skip(numToSkip);
>             if (skipped == 0) {
>                 break;
>             }
> And the input stream javadoc says:
> "     * This may result from any of a number of conditions; reaching end of file
>      * before <code>n</code> bytes have been skipped is only one possibility."
> In the case of CipherInputStream, it stops at the end of each byte buffer.
> If you check the IOUtils from colleagues at commons-io, they have considered this case
in IOUtils.skip() where they use a read to skip through the stream.
> An optimized version could combine trying to skip, then read then trying to skip again.



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

Mime
View raw message