Messages in this thread | | | Date | Sun, 17 Jun 2001 10:03:10 -0700 | From | "H. Peter Anvin" <> |
| |
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.
-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/
| |