[Lzip-bug] why not offer a real 'zip' function using lzip?

[Linda A. Walsh]

I.e. Making a single random-access file archive like 'zip'.
I knew about lzma, (I alias it to 'lz', even though it conflicts
with some stupid dosapp for no good reason (on suse anyway), xz,
and 7zip -- at least 7zip produces a zip file -- and stores
directories and file structure.

Why not offer a similar mode for lzip -- they are alot more
portable when they are one file then it might catch on as an
archive format.  If it's just another compression program like
gzip/bzip2 (that both, inherently use 'tar' to store directory
formats, but that are not random access), I'm not sure how far
it will go.  **Especially** since gnu-tar has already added lzma
support and it does a pretty good job. 

BTW, here was my tests on a 200M directory using several compression
progs (including lzip):

1k blocks

207304  ADHD_in_adults/             Source dir
205744  ADHD_in_adults.tar       uncompressed tar
157968  ADHD_in_adults.tar.lzop  lzop program on the tar
*141936  ADHD_in_adults-lzip/     lzip called on each file
*139552  ADHD_in_adults-lzip.tar  tar of lzip'ed files
138344  ADHD_in_adults.zipx      winzip 'highest' compression
*110540  ADHD_in_adults.tar.lzip  lzip on the tar
110468  ADHD_in_adults.tar.xz    xz on tar
110468  ADHD_in_adults.iso.lzma  lzma of the iso
110448  ADHD_in_adults.tlz       lzma of the tar
110212  ADHD_in_adults.uniz.7z   unix version of 7zip (4 procs/4 streams)
110176  ADHD_in_adults.7z        windows version

Noise or not, you're going to have a hard time beating the flexibility
and speed of 7zip.  I looked over an earlier version of his code and never
could find the right params to make it run well on everything.

I did find 1 case where bzip2 beat lzma, but it was a single, relatively
small file.

But My point in the email was look at the diff between running lzip on
each file individual vs. a tar of them (~2.4M savings) lzip on a stream
(the tar) (~32M savings!).

The final results show all the lz's within <1% of each other.  7z was way
fast using 4 procs (at expense of 36K disk space).

Maybe you could enhance the existing 'zip' program using your 
algorithm/code?

That would be a killer improvement! :-)  It would have zip compatibility, in
structure, but have the good compression.  Be sure to support unicode -- 
UTF-8
would be best -- you might beat 7z, he uses UTF-16!  What a dork! :-)