115 lines
5.5 KiB
Plaintext
115 lines
5.5 KiB
Plaintext
Known, current PKZIP bugs/limitations:
|
|
-------------------------------------
|
|
|
|
- PKUNZIP 2.04g is reported to corrupt some files when compressing them with
|
|
the -ex option; when tested, the files fail the CRC check, and comparison
|
|
with the original file shows bogus data (6K in one case) embedded in the
|
|
middle. PKWARE apparently characterized this as a "known problem."
|
|
|
|
- PKUNZIP 2.04g considers volume labels valid only if originated on a FAT
|
|
file system, but other OSes and file systems (e.g., Amiga and OS/2 HPFS)
|
|
support volume labels, too.
|
|
|
|
- PKUNZIP 2.04g can restore volume labels created by Zip 2.x but not by
|
|
PKZIP 2.04g (OS/2 DOS box only??).
|
|
|
|
- PKUNZIP 2.04g gives an error message for stored directory entries created
|
|
under other OSes (although it creates the directory anyway), and PKZIP -vt
|
|
does not report the directory attribute bit as being set, even if it is.
|
|
|
|
- PKZIP 2.04g mangles unknown extra fields (especially OS/2 extended attri-
|
|
butes) when adding new files to an existing zipfile [example: Walnut Creek
|
|
Hobbes March 1995 CD-ROM, FILE_ID.DIZ additions].
|
|
|
|
- PKUNZIP 2.04g is unable to detect or deal with prepended junk in a zipfile,
|
|
reporting CRC errors in valid compressed data.
|
|
|
|
- PKUNZIP 2.04g (registered version) incorrectly updates/freshens the AV extra
|
|
field in authenticated archives. The resultant extra block length and total
|
|
extra field length are inconsistent.
|
|
|
|
- [Windows version 2.01] Win95 long filenames (VFAT) are stored OK, but the
|
|
file system is always listed as ordinary DOS FAT.
|
|
|
|
- [Windows version 2.50] NT long filenames (NTFS) are stored OK, but the
|
|
file system is always listed as ordinary DOS FAT.
|
|
|
|
- PKZIP 2.04 for DOS encrypts using the OEM code page for 8-bit passwords,
|
|
while PKZIP 2.50 for Windows uses Latin-1 (ISO 8859-1). This means an
|
|
archive encrypted with an 8-bit password with one of the two PKZIP versions
|
|
cannot be decrypted with the other version.
|
|
|
|
- PKZIP for Windows GUI (v 2.60), PKZIP for Windows command line (v 2.50) and
|
|
PKZIP for Unix (v 2.51) save the host's native file timestamps, but
|
|
only in a local extra field. Thus, timestamp-related selections (update
|
|
or freshen, both in extraction or archiving operations) use the DOS-format
|
|
localtime records in the Zip archives for comparisons. This may result
|
|
in wrong decisions of the program when updating archives that were
|
|
previously created in a different local time zone.
|
|
|
|
- PKZIP releases newer than PKZIP for DOS 2.04g (PKZIP for Windows, both
|
|
GUI v 2.60 and console v 2.50; PKZIP for Unix v 2.51; probably others too)
|
|
use different code pages for storing filenames in central (OEM Codepage)
|
|
and local (ANSI / ISO 8859-1 Codepage) headers. When a stored filename
|
|
contains extended-ASCII characters, the local and central filename fields
|
|
do not match. As a consequence, Info-ZIP's Zip program considers such
|
|
archives as being corrupt and does not allow to modify them. Beginning
|
|
with release 5.41, Info-ZIP's UnZip contains a workaround to list AND
|
|
extract such archives with the correct filenames.
|
|
Maybe PKWARE has implemented this "feature" to allow extraction of their
|
|
"made-by-PKZIP for Unix/Windows" archives using old (v5.2 and earlier)
|
|
versions of Info-ZIP's UnZip for Unix/WinNT ??? (UnZip versions before
|
|
v 5.3 assumed that all archive entries were encoded in the codepage of
|
|
the UnZip program's host system.)
|
|
|
|
- PKUNZIP 2.04g is reported to have problems with archives created on and/or
|
|
copied from Iomega ZIP drives (irony, eh?).
|
|
|
|
Known, current WinZip bugs/limitations:
|
|
--------------------------------------
|
|
|
|
- [16-bit version 6.1a] NT short filenames (FAT) are stored OK, but the
|
|
file system is always listed as NTFS.
|
|
|
|
- WinZip doesn't allow 8-bit passwords, which means it cannot decrypt an
|
|
archive created with an 8-bit password (by PKZIP or Info-ZIP's Zip).
|
|
|
|
- WinZip (at least Versions 6.3 PL1, 7.0 SR1) fails to remove old extra
|
|
fields when freshening existing archive entries. When updating archives
|
|
created by Info-ZIP's Zip that contain UT time stamp extra field blocks,
|
|
UnZip cannot display or restore the updated (DOS) time stamps of the
|
|
freshened archive members.
|
|
|
|
Known, current other third-party Zip utils bugs/limitations:
|
|
------------------------------------------------------------
|
|
|
|
- Asi's PKZip clones for Macintosh (versions 2.3 and 2.10d) are thoroughly
|
|
broken. They create invalid Zip archives!
|
|
a) For the first entry, both compressed size and uncompressed length
|
|
are recorded as 0, despite the fact that compressed data of non-zero
|
|
length has been added.
|
|
b) Their program creates extra fields with an (undocumented) internal
|
|
structure that violates the requirements of PKWARE's Zip format
|
|
specification document "appnote.txt": Their extra field seems to
|
|
contain pure data; the 4-byte block header consisting of block ID
|
|
and data length is missing.
|
|
|
|
Possibly current PKZIP bugs:
|
|
---------------------------
|
|
|
|
- PKZIP (2.04g?) can silently ignore read errors on network drives, storing
|
|
the correct CRC and compressed length but an incorrect and inconsistent
|
|
uncompressed length.
|
|
|
|
- PKZIP (2.04g?), when deleting files from within a zipfile on a Novell
|
|
drive, sometimes only zeros out the data while failing to shrink the
|
|
zipfile.
|
|
|
|
Other limitations:
|
|
-----------------
|
|
|
|
- PKZIP 1.x and 2.x encryption has been cracked (known-plaintext approach;
|
|
see http://www.cryptography.com/ for details).
|
|
|
|
[many other bugs in PKZIP 1.0, 1.1, 1.93a, 2.04c and 2.04e]
|