On 2011-08-06, Torsten Curdt wrote:
>> The only case that isn't covered so far is compressed / non-seekable >> output / input of unknown size. > WTF > How does the input stream distinguish between entry data and stream > data if the length is not know up front? The DEFLATE algorithm signals when the stream is terminated so the input streams knows when its done. The data descriptor following the entry data merely serves to verify the data that has just been read. This already works for "normal ZIP", we just need to support the different formats of data descriptors properly. Actually ZipArchiveInputStream even supports non-compressed entries of unknown size if you ask it to - but it is highly recommended that you don't. It does so by assuming that whenever it encounters anything that looks like a "data descriptor", a "local file header" or a "central directory entry" then it must have reached the next entry. This is neither reliable nor does it perform well, but it is required to support some archives found in the wild (some Microsoft XPS documents IIRC). Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
