Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
MIME-Version: 1.0
From: Damjan Jovanovic <damjan@apache.org>
Date: Wed, 13 Nov 2013 15:28:04 +0200
Message-ID: 
 <CAJm2B-=aaUU=Ae66+86sKzLLBzWTT8P6gkBpPH0c6eQCHOuB4g@mail.gmail.com>
Subject: Re: [compress] Random access of SevenZFile
To: Commons Users List <user@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 13, 2013 at 3:18 PM,  <org.apache.commons@io7m.com> wrote:
> On Wed, 13 Nov 2013 06:05:06 +0100
> Stefan Bodewig <bodewig@apache.org> wrote:
>
>> On 2013-11-12, <org.apache.commons@io7m.com> wrote:
>>
>> > The 7z file format is (supposedly) a random access format, much like
>> > zip archives. However, The SevenZFile class seems to only expose a
>> > sequential interface (where I'm expected to seek over entries one at a
>> > time, presumably whilst unpacking files).
>>
>> Much like zip 7z has file metadata at the end of the archive, so yes,
>> SevenZFile could build up a Map when opening the archive and provide
>> random access.  Actually it does collect the information of all entries
>> (in Archive.files), only an API to use it for random access is missing.
>>
>> Things aren't all that bad, though.  Repeatedly calling getNextEntry
>> will create streams for each entry but not consume them - so the files
>> are not unpacked while you iterate over the entries.
>>
>> Stefan
>
> Hello!
>
> I spent a bit of time yesterday implementing this; I build a HashMap of
> names to SevenZArchiveEntry instances by iterating over all entries upon
> archive loading.
>
> However, I'm having further problems actually obtaining streams to specific
> entries. The only interface exposed by SevenZFile is a set of mostly
> undocumented read() functions that don't state where the data comes from.
> The documentation for the no-argument read() function states
> "Read a byte of data".
>
> I'm assuming that the functions will actually read from the byte offset
> in the file described by the most recent entry returned by getNextEntry().
> Unfortunately, given that there's apparently no way to seek, this seems to
> imply that I can't do anything with a SevenZFile beyond sequentially
> decompressing all entries in order. This makes it essentially useless for
> my needs (writing an interactive archive management program).
>
> Am I missing something obvious here?
>
> M

It is not possible to seek to an arbitrary file's contents in a 7z
archive anyway, since 7z archives can use solid compression for some
or all files, which means you potentially have to sequentially
decompress some or all of the preceding files' contents to get to the
contents of the one you want.

Damjan

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org