Bill Studenmund wrote:

> It just strikes me as gross and weird that you probably would be able to
> cd into a file.

That is a user interface which can work extremely well for container 
files such as zip files, tar files etc.

One such system which implemented this is Acorn's RISC OS. In RISC OS a 
filesystem object can be a file, a directory or an "image file". An 
"image file" means that you can reasonably access it both as a file and 
as a directory.

A file is an image file if a filesystem module has registered with the 
kernel as being capable of handling files of that type. (RISC OS had 
filetypes, which made this kind of registration easier. While you can't 
do registration in quite the same way in NetBSD, there are clearly many 
other ways to achieve the same goal)

The primary user of image filesystems which shipped with the OS was 
DOSFS. This was extremely useful in conjunction with the PC emulator, 
which used an image file for the emulated hard drive. Want to grab files 
from the PC side, or write to it? Easy, just go into that directory and 
play.

The most useful third-party user of image filesystems was SparkFS. 
Suddenly, spark files, zip files and a bunch of common compression 
formats are supported as full-on read/write directories and virtually 
all other compression formats from the time are readable as directories.

There is simply no other way to run complex applications directly out of 
an archive without extracting it into a regular filesystem first. The 
hacks to try to pretend this in, eg, Windows XP, don't really work.

Back to NetBSD - I think something similar to this would be a good idea. 
I'm not sure exactly how it would look, but I think it would basically 
boil down to some sort of automounting, and possibly a filesystem that 
does most of its work in userland.

-- 
Gilette - the best a man can forget