From owner-freebsd-hackers Thu Oct 23 09:12:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA06928 for hackers-outgoing; Thu, 23 Oct 1997 09:12:09 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from word.smith.net.au (word.smith.net.au [202.0.75.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA06826 for ; Thu, 23 Oct 1997 09:11:45 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id BAA01020; Fri, 24 Oct 1997 01:37:03 +0930 (CST) Message-Id: <199710231607.BAA01020@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Luigi Rizzo cc: hackers@FreeBSD.ORG Subject: Re: zipfs filesystem anyone ? In-reply-to: Your message of "Thu, 23 Oct 1997 07:38:26 +0100." <199710230638.HAA26030@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Oct 1997 01:37:03 +0930 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Thus, I was looking at something which would pass all filesystem > (or vn ?) calls to some user-space process which could then handle > them properly. Look at the 'rumba' port for an example of using the NFS interface to achieve this. > NOTE 2: Why ZIP and not .tar.gz > > Implementing such a "filesystem" in user space is much easier if the > directory structure is directly available in the archive, rather than > being scattered all around and mixed with data. gzipped tar files have > this problem: you need to decompress data before being able to use > them. Conversely, I think zip archives have the directory structure in > clear and so it is easier to move through the tree, and decompression > is only necessary on the single components. You are correct; gzipped tarfiles are organised the wrong way around (metadata inside the compressed envelope), while zipfiles keep the metadata outside. mike