Diego Roversi <[EMAIL PROTECTED]> writes: > Compressed store make sense only if the are readonly or used with a > "substore" that can shrink or grow at will. That happens because you can't > know how well data can be compressed. The only way to handle correctly is to > compress the data at fs layer (see e2compress: a modified ext2).
One interesting hack (but it would be a translator, not a storeio thing) is a translator that can be mounted on a directory, and transparently unzips all files in the directory. Say the translator is mounted on /foo, and uses another directory /foo_compressed for underlying storage. Then I can access /foo/file.txt and the translator will open /foo_compressed.txt.gz and unzip it automatically while it is read. If one introduce some restrictions, like not supporting seeking backwards, it can be quite simple. Optionally, the translator can support the creation of new files, the simplest way would be to store the data uncompressed in /foo_compressed, and optionally compress the file after it is closed. I remember using a similar filesystem hack on the Amiga a long time back, and I stored most documentation, as well as a lot of reference sourcecode and all elisp files, in the autocompressed filesystem. I think it is a cleaner approach than putting gzip support into all sorts of programs or into libc. Regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
