Re: [isocompr PATCH]: first comparison with HPA's zisofs

["H. Peter Anvin" <hpa@zytor.com>]

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