Details | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
6725 | siemargl | 1 | Known, 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 | |||
68 | Known, 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 | |||
83 | Known, 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 | |||
97 | Possibly 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 | |||
108 | Other 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] |