On 2013-01-17, Bear Giles wrote:
> I think a number of applications use a concatenation of a standard archive
> format and custom data.
Absolutely, and I think we should support that use-case.
I'll try to free up some coding time this weekend.
Stefan
---
I think a number of applications use a concatenation of a standard archive
format and custom data. The most well known probably is .rpm which is/was a
cpio stream immediately followed by additional information (iirc - it might
go the other way). In any case a developer might expect to have the inpu
> For tar it would be one block (usualy 512 bytes), for zip the full
> central directory has to be read which could be quite a bit.
>
Urgh. Because that's at the end for zips? That's not so good then.
>
> I currently plan to implement it inside getNextEntry as it is cleaner.
> In the tar case I
On 2013-01-17, Torsten Curdt wrote:
> If we see `getNextEntry` return null we should position the stream at
> the end of the archive. I think that's your (1). Sounds simpler and
> more straight forward from an API POV. IIUC that reading should only
> be a few bytes. A second EOF marker for TAR f
Late reply but anyway.
If we see `getNextEntry` return null we should position the stream at the
end of the archive.
I think that's your (1). Sounds simpler and more straight forward from an
API POV.
IIUC that reading should only be a few bytes. A second EOF marker for TAR
for example.
Did I get
Hi all,
COMPRESS-202 and COMPRESS-206 only talk about TAR but something similar
aplies at least to ZIP as well: once we detect that an archive doesn't
contain any more entries, we stop reading the input stream, even if it
contains more stuff that is part of the archive. This causes problems
for u
