Hi,
On Fri, Aug 30, 2013 at 12:19 AM, Mateusz Viste
mate...@viste-family.net wrote:
On 08/30/2013 06:42 AM, Rugxulo wrote:
IIRC, the default mode of 7za is -mx5 and .7z format using LZMA [or
LZMA2 in newer alphas] method, which means (among other things) 16 MB
dictionary, aka 2^24, aka LZMA:24 (but you can adjust that).
This is right. But bigger dictionary doesn't necessarily mean
'better'. well, sure, it means 'potentially better compression ratio',
because we can seek back redundant data in wider spans, but it also
means 'tremendously higher memory requirements'. This is why I don't
create FDNPKG packages using LZMA (unless for pure experimentation),
even though it's 5-15% smaller than DEFLATE. Trying to uncompress an
LZMA file on a 16MB RAM machine is hell (or simply impossible if no
virtual memory is available).
While some compressors use a minimum dictionary size regardless of the
file size (e.g. bzip2 defaults to 900k unless explicitly told
otherwise), 7-Zip is apparently smarter. At least, my one-floppy DJGPP
.7z file only uses 6m (6 MB, roughly the size of all files
unpacked), so I did correctly decompress it (years ago), without
swapping or slowdown, on a 486 with 7 MB of extended RAM. This was not
possible with UHarc, which needed approx. 24 MB (by default with
-mx, I think).
And like I said, you can make the dictionary bigger or smaller,
depending on need. I don't remember the limits, perhaps 1 GB is max.
And BTW, just for more arcane useless trivia, CWSDPMI won't allocate
the total RAM size requested for its swapfile unless it is actually
used (unlike Causeway), which is of course a more efficient way of
doing things.
Even .ZIP format can officially support Bzip2 or even LZMA
method (or others).
That's exactly what FDNPKG supports - LZMA-compressed files inside ZIP
'slots'. This allows using the cool ZIP structure for handling files
(and extracting only these we need - eg. without SOURCES), but still
benefiting from the LZMA compression ratio.
IIRC, zip 3.0 and unzip 6.00 both optionally support bzip2's
compression method via libbz2 (or whatever it's called) at compile
time (see unzip -v and zip -Z bzip2). E.g. my native Windows
versions here do and don't support it (but Cygwin zip does). Though I
don't know why there was never an official build of zip 3.0 for DOS.
(I vaguely recall some tmpfile bug, but it wasn't pressing enough for
me to care. I presume that others were similarly less interested, as
always.)
indeed, .gz is designed to compress only a single file. No 'directory
storage' capabilities there. Still, for 'single file' compression I'd
use gzip over zip anytime. It's fits better, because it provides all we
need, without any additional garbage (mostly limited to filename + CRC32
+ a few flags).
Well, as usual, things are as complicated as you make them. Yes, .ZIP
has some minor overhead, but like I said, it's not technically true
that it's always smaller to use .gz (or even .bz2) instead of .zip.
Some tools don't handle both .gz and .tar.gz, e.g. DJGPP's djtar only
handles the latter (and also .tar.bz2 in beta djdev204.zip ... and
of course plain .tar and .zip). GNU gzip can unpack a .zip if it only
has one file inside, but I don't think the *BSD equivalent has that
feature. Yeah, I know, minor stuff, but it's somewhat annoying when
your options are limited (e.g. no network connection or no compiler or
similar trivial problem).
Usually but not always. 7-Zip provides its own improved Deflate,
which is slightly better
On a side note: some decompressors have troubles handling the 7zip
'deflated zip' files sometimes. For example kunzip crashes on some zip
files created by 7za, while it doesn't crash on any other files created
with 'classic' zippers.
There are literally dozens of decompressors for .zip files. It would
be impossible, even with standard appnote.txt, for them all to fully
comply. I've not seen any huge problems, but it's always possible. If
you (or yours) use kunzip much, maybe that's a concern, but since I
(naively?) don't consider that a widely-used implementation, I'm not
too worried.
I mean, Ubuntu has unzip by default, last I checked, and of course
Windows Explorer supports unzipping since I don't know when (ME? XP?).
Even *BSD has a partial implementation of unzip too (libarchive?). In
other words, I don't personally see a huge need for kunzip, but the
more the merrier! :-)
Well, adding is easy (you just strip the directory from the end, append
your file and recreate the directory).
Deleting is trickier, indeed.. (need to move all data around to cover
the empy hole left by the deleted file, and recalculate all data offsets
in both the central directory and per-file headers...).
I'm not sure how well most tools handle this. The naive approach would
be to temporarily duplicate the entire file, which may be unfeasible
with very large sizes.
