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
