Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!uunet!shelby!agate!eris.berkeley.edu!doug
From: doug@eris.berkeley.edu (Doug Merritt)
Newsgroups: comp.sys.amiga.misc
Subject: Re: A compression filesystem
Message-ID: <1991Feb18.005236.8760@agate.berkeley.edu>
Date: 18 Feb 91 00:52:36 GMT
References: <71.27BCCBB8@weyr.FIDONET.ORG> <18b2ca89.ARN2bfd@prolix.pub.uu.oz.au>
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: University of California, Berkeley
Lines: 23

In article <18b2ca89.ARN2bfd@prolix.pub.uu.oz.au> dac@prolix.pub.uu.oz.au writes:
>The 'KISS' approach is best. Keep It Simple, Stupid. If people want to put
>more data on their devices, they should BUY larger storage capability
>devices. As simple as that.

Not quite. One approach still makes sense (this is something I was
thinking of doing for several years, but it doesn't look like I'll
ever get to it): have a "compression file system" which works on
top of the regular one, so that individual files can be read/written
as compressed files transparently. Access would be something
like "type pak:dh0/directory/file.Z", where "pak:" is the device
that knows about compression, and "file.Z" is a previously compressed
file.

This lets all compressed files be directly visible to all programs,
something you can't really get any other way.

The same approach makes similar sense (maybe even more so) for
archives (zoo, lharc, arc, etc). Including cd'ing into archives.
	Doug
--
Doug Merritt		doug@eris.berkeley.edu (ucbvax!eris!doug)
		or	uunet.uu.net!crossck!dougm