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-239) ArchiveStreamFactory cannot create an ArchiveInputStream from any input stream that is blocking
Date Fri, 04 Oct 2013 07:12:46 GMT

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

Stefan Bodewig commented on COMPRESS-239:
-----------------------------------------

should be easy to fix.

If you know you are reading a ZIP you can certainly skip the autodetection version of createArchiveInputStream
as a workaround, but you aleady knew that.

> ArchiveStreamFactory cannot create an ArchiveInputStream from any input stream that is
blocking
> -----------------------------------------------------------------------------------------------
>
>                 Key: COMPRESS-239
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-239
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.5
>         Environment: Windows Server 2008r1/r2, Ubuntu 12.10
>            Reporter: Jon Neel
>              Labels: easyfix
>             Fix For: 1.6
>
>
> Encountered while streaming zip data over a network:
> In the createArchiveInputStream method of ArchiveStreamFactory, when the provided input
stream is read, and it blocks before 12 bytes are available for reading, due to the contract
of the java.io.InputStream class, the archive signature will not be completely read, and an
ArchiveException will be thrown ("No Archiver found for the stream signature").
> In ZipArchiveInputStream, you have implemented a readFully method, which should solve
this issue, but since you are checking the length of the signature read against the expected
length, you are never getting to do that.  When you try to read the signature, you should
be using readFully.
> For reference, here is important part of the contract of java.io.InputStream.read():
> This method blocks until [ANY] input data is available, end of file is detected, or an
exception is thrown.
> If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt
to read _at least one byte_. If no byte is available because the stream is at end of file,
the value -1 is returned; otherwise, at least one byte is read and stored into b.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message