[
https://issues.apache.org/jira/browse/COMPRESS-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980950#comment-13980950
]
Fabian Lange commented on COMPRESS-277:
---------------------------------------
That doesn't make sense.
The semantics of getNextEntry are so that it will seek you to the next entry.
compare to JDK ZipInputStream:
/**
* Reads the next ZIP file entry and positions the stream at the
* beginning of the entry data.
* @return the next ZIP file entry, or null if there are no more entries
* @exception ZipException if a ZIP file error has occurred
* @exception IOException if an I/O error has occurred
*/
public ZipEntry getNextEntry() throws IOException {
Also, why should the user now need to care about seeking the next entry? it
just doesnt make sense for me.
The defined api and code are fine! Its just that it was buggy in the case skip
did not skip as much as expected. That has been fixed, and I don't see a reason
to hijack this Ticket to completely change the semantics of the API.
> 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
>
> Attachments: TarArchiveInputStream.java.patch
>
>
> 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)
