From owner-freebsd-hackers Thu Oct 23 00:54:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA07316 for hackers-outgoing; Thu, 23 Oct 1997 00:54:49 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id AAA07305 for ; Thu, 23 Oct 1997 00:54:34 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA26030; Thu, 23 Oct 1997 07:38:27 +0100 From: Luigi Rizzo Message-Id: <199710230638.HAA26030@labinfo.iet.unipi.it> Subject: zipfs filesystem anyone ? To: hackers@freebsd.org Date: Thu, 23 Oct 1997 07:38:26 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was thinking of possible solutions for implementing a "zip file system", ie a method to access pieces of a compressed archive as if they were mounted in the filesystem [see Note 1 and 2] Basically I would like to do something like vnconfig /dev/vn0 /usr/distfiles/ports.zip mount -t zipfs /dev/vn0 /usr/ports The obvious approach of creating a new filesystem type is not very attractive though, for the complexity involved in this work and also for debugging purposes. 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. Using this approach, little modifications to, say, a standard "unzip" program, would permit such a filesystem to be implemented relatively easily. Efficiency is not a major concern for this type of application (especially because the typical use would be sequential access to files). I have been looking at the portal filesystem, but this only provides an "open" service, i.e. only the open() call is passed to the user-space process. So I think my only choice is to try a merge of the "portal" and "nullfs" filesystem to build the thing I need. But maybe such implementations already exist, in some form or some other ? NOTE 1: Motivation The motivation for this is relatively simple. Many times one needs to browse through things like a software package, which are available as a compressed archive. The common approach is to extract the archive to the filesystem and then use the file. But this approach tends to leave garbage on your disk, and is time-consuming (ever noticed how slow is to extract ports.tgz with its thousands of files and directories ?). 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. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________