1Known, current PKZIP bugs/limitations: 2------------------------------------- 3 4 - PKUNZIP 2.04g is reported to corrupt some files when compressing them with 5 the -ex option; when tested, the files fail the CRC check, and comparison 6 with the original file shows bogus data (6K in one case) embedded in the 7 middle. PKWARE apparently characterized this as a "known problem." 8 9 - PKUNZIP 2.04g considers volume labels valid only if originated on a FAT 10 file system, but other OSes and file systems (e.g., Amiga and OS/2 HPFS) 11 support volume labels, too. 12 13 - PKUNZIP 2.04g can restore volume labels created by Zip 2.x but not by 14 PKZIP 2.04g (OS/2 DOS box only??). 15 16 - PKUNZIP 2.04g gives an error message for stored directory entries created 17 under other OSes (although it creates the directory anyway), and PKZIP -vt 18 does not report the directory attribute bit as being set, even if it is. 19 20 - PKZIP 2.04g mangles unknown extra fields (especially OS/2 extended attri- 21 butes) when adding new files to an existing zipfile [example: Walnut Creek 22 Hobbes March 1995 CD-ROM, FILE_ID.DIZ additions]. 23 24 - PKUNZIP 2.04g is unable to detect or deal with prepended junk in a zipfile, 25 reporting CRC errors in valid compressed data. 26 27 - PKUNZIP 2.04g (registered version) incorrectly updates/freshens the AV extra 28 field in authenticated archives. The resultant extra block length and total 29 extra field length are inconsistent. 30 31 - [Windows version 2.01] Win95 long filenames (VFAT) are stored OK, but the 32 file system is always listed as ordinary DOS FAT. 33 34 - [Windows version 2.50] NT long filenames (NTFS) are stored OK, but the 35 file system is always listed as ordinary DOS FAT. 36 37 - PKZIP 2.04 for DOS encrypts using the OEM code page for 8-bit passwords, 38 while PKZIP 2.50 for Windows uses Latin-1 (ISO 8859-1). This means an 39 archive encrypted with an 8-bit password with one of the two PKZIP versions 40 cannot be decrypted with the other version. 41 42 - PKZIP for Windows GUI (v 2.60), PKZIP for Windows command line (v 2.50) and 43 PKZIP for Unix (v 2.51) save the host's native file timestamps, but 44 only in a local extra field. Thus, timestamp-related selections (update 45 or freshen, both in extraction or archiving operations) use the DOS-format 46 localtime records in the Zip archives for comparisons. This may result 47 in wrong decisions of the program when updating archives that were 48 previously created in a different local time zone. 49 50 - PKZIP releases newer than PKZIP for DOS 2.04g (PKZIP for Windows, both 51 GUI v 2.60 and console v 2.50; PKZIP for Unix v 2.51; probably others too) 52 use different code pages for storing filenames in central (OEM Codepage) 53 and local (ANSI / ISO 8859-1 Codepage) headers. When a stored filename 54 contains extended-ASCII characters, the local and central filename fields 55 do not match. As a consequence, Info-ZIP's Zip program considers such 56 archives as being corrupt and does not allow to modify them. Beginning 57 with release 5.41, Info-ZIP's UnZip contains a workaround to list AND 58 extract such archives with the correct filenames. 59 Maybe PKWARE has implemented this "feature" to allow extraction of their 60 "made-by-PKZIP for Unix/Windows" archives using old (v5.2 and earlier) 61 versions of Info-ZIP's UnZip for Unix/WinNT ??? (UnZip versions before 62 v 5.3 assumed that all archive entries were encoded in the codepage of 63 the UnZip program's host system.) 64 65 - PKUNZIP 2.04g is reported to have problems with archives created on and/or 66 copied from Iomega ZIP drives (irony, eh?). 67 68Known, current WinZip bugs/limitations: 69-------------------------------------- 70 71 - [16-bit version 6.1a] NT short filenames (FAT) are stored OK, but the 72 file system is always listed as NTFS. 73 74 - WinZip doesn't allow 8-bit passwords, which means it cannot decrypt an 75 archive created with an 8-bit password (by PKZIP or Info-ZIP's Zip). 76 77 - WinZip (at least Versions 6.3 PL1, 7.0 SR1) fails to remove old extra 78 fields when freshening existing archive entries. When updating archives 79 created by Info-ZIP's Zip that contain UT time stamp extra field blocks, 80 UnZip cannot display or restore the updated (DOS) time stamps of the 81 freshened archive members. 82 83Known, current other third-party Zip utils bugs/limitations: 84------------------------------------------------------------ 85 86 - Asi's PKZip clones for Macintosh (versions 2.3 and 2.10d) are thoroughly 87 broken. They create invalid Zip archives! 88 a) For the first entry, both compressed size and uncompressed length 89 are recorded as 0, despite the fact that compressed data of non-zero 90 length has been added. 91 b) Their program creates extra fields with an (undocumented) internal 92 structure that violates the requirements of PKWARE's Zip format 93 specification document "appnote.txt": Their extra field seems to 94 contain pure data; the 4-byte block header consisting of block ID 95 and data length is missing. 96 97Possibly current PKZIP bugs: 98--------------------------- 99 100 - PKZIP (2.04g?) can silently ignore read errors on network drives, storing 101 the correct CRC and compressed length but an incorrect and inconsistent 102 uncompressed length. 103 104 - PKZIP (2.04g?), when deleting files from within a zipfile on a Novell 105 drive, sometimes only zeros out the data while failing to shrink the 106 zipfile. 107 108Other limitations: 109----------------- 110 111 - PKZIP 1.x and 2.x encryption has been cracked (known-plaintext approach; 112 see http://www.cryptography.com/ for details). 113 114[many other bugs in PKZIP 1.0, 1.1, 1.93a, 2.04c and 2.04e] 115