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! :-)
_______________________________________________
Lzip-bug mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lzip-bug
