contents of the zip file but cannot extract it anyway (because
of the new compression algorithm). If you do not use encryption and use
regular disk files, you do not have to care about this problem.
Under VMS, not all of the odd file formats are treated properly. Only
stream‐LF format zip files are expected to work with zip. Others can be
converted using Rahul Dhesi’s BILF program. This version of zip handles
some of the conversion internally. When using Kermit to transfer zip
files from VMS to MSDOS, type "set file type block" on VMS. When trans‐
ferring from MSDOS to VMS, type "set file type fixed" on VMS. In both
cases, type "set file type binary" on MSDOS.
Under some older VMS versions, zip may hang for file specifications that
use DECnet syntax foo::*.*.
On OS/2, zip cannot match some names, such as those including an excla‐
mation mark or a hash sign. This is a bug in OS/2 itself: the 32‐bit
DosFindFirst/Next don’t find such names. Other programs such as GNU tar
are also affected by this bug.
Under OS/2, the amount of Extended Attributes displayed by DIR is (for
compatibility) the amount returned by the 16‐bit version of DosQuery‐
PathInfo(). Otherwise OS/2 1.3 and 2.0 would report different EA sizes
when DIRing a file. However, the structure layout returned by the
32‐bit DosQueryPathInfo() is a bit different, it uses extra padding
bytes and link pointers (it’s a linked list) to have all fields on
4‐byte boundaries for portability to future RISC OS/2 versions. There‐
fore the value reported by zip (which uses this 32‐bit‐mode size) dif‐
fers from that reported by DIR. zip stores the 32‐bit format for porta‐
bility, even the 16‐bit MS‐C‐compiled version running on OS/2 1.3, so
even this one shows the 32‐bit‐mode size.
AUTHORS
Copyright (C) 1997‐2008 Info‐ZIP.
Currently distributed under the Info‐ZIP license.
Copyright (C) 1990‐1997 Mark Adler, Richard B. Wales, Jean‐loup Gailly,
Onno van der Linden, Kai Uwe