[lkml]   [2001]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Roberto Di Cosmo wrote:

> I have only the following (minor) criticisms
> - the transparent compression scheme does not rely on a special
> filename extension (it was .gZ in isocompr): a file foo gets
> compressed to a file foo, and the only way to see if foo is
> compressed or not is to read the header. This has pros and cons...
> and I wonder what the reasons of this choice are.

It caused ALL kinds of nastiness; the chosen solution was vastly simpler
on a whole bunch of axes.

> - the tools allow to compress/decompress only a whole directory tree,
> while it should be possible to act on a single file also: in DemoLinux
> not all files are compressed (some must be readable under (hem...) other
> less interesting OSs for example ;-)) and the distinction is not on
> a per-directory basis.
> [easy to fix, see patch at the end of this message: I did this to
> be able to try zisofs with DemoLinux]

You can do this by having the compressed and uncompressed files in
different directory trees and merge them using mkisofs. I personally
think that's a cleaner solution, even if your suggestion might make
sense anyway. Your patch, though, is too ugly to live.

> - it seems to me that this was written with 2.4.x in mind, and I did not
> find a version for 2.2.x kernels :-(
> Now I wonder, if zisofs is going to be included into 2.5 (I would strongly
> vote in favour!), would it be worthwhile to include a compatibility mode
> to read the isocompr blocksized format too?

No. isocompr was misdesigned, and such a compatibility mode would
needlessly complicate everything.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.114 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site