>
>
> 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.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/