Re: gvfs archive backend

[Tim Kientzle <kientzle freebsd org>]

Benjamin Otte wrote:
> I've recently been investigating how hard it would be to provide a way
> for Gnome's new gvfs virtual filesystem to "mount" archives [1].

Yours would not be the first such project I've
heard of.

For read-only access, I think that libarchive isn't a bad
way to go, although it's focus on streaming may make it
a bit less efficient for the application you have in
mind.  As you observed, update is a much trickier proposition.

To answer a couple of questions you asked specifically about
libarchive:
 * It already reads both Zip and ISO9660, though it
   does use a streaming strategy that does not give it
   access to all features of such files.
 * Libarchive does use forward seeks to optimize reading
   listings from large uncompressed archives and does
   advertise the current file offset within the archive.
   Using these two features, you should able to rapidly
   skim any archive to generate a complete directory listing
   with offsets and then seek to read any single entry.
   (This won't work for ISO9660, but should work fine
   for tar, cpio, zip.)

I think the key question you have to figure out is whether
you want support for "generic archives" (including tar, cpio,
etc) or whether you want to support one or two very specific
formats.

The advantage of implementing specific formats is that you
can take advantage of those formats in deep ways.  The Zip
file format in particular was designed with incremental
update in mind and should work well for this type of
application.

Supporting archive mounting in a very generic fashion will
probably require you to make some sacrifices:  Either
you'll have a pretty complex infrastructure or have to
sacrifice some functionality.  Libarchive chose to sacrifice
some functionality largely in order to limit complexity.

As for adding random-access support to libarchive, I can only
say that I'm ambivalent.  It could be a nice addition, but it's
not a priority for me.  I'll certainly consider any code that
someone might send my way that implements such features, but
whether I include it into my sources will depend on how well
it integrates with the other things I'm trying to do.  (In
particular, I won't sacrifice streaming to support random
access.)  Anyone wishing to implement such an ambitious new
feature should definitely familiarize themselves with the
libarchive_test suite first.  ;-)

Of course, the code is openly licensed and you're welcome to
copy any parts of it that you find useful or even fork the
whole project if you like.  (I do, of course, ask that you
honor and preserve the existing source licenses.)

Let me know what you decide to do, even if you decide
not to use libarchive.

> One last question: Are you on IRC?

No, but I generally respond to email pretty quickly.

Cheers,

Tim Kientzle