home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / compress / 4798 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  8.5 KB

  1. Path: sparky!uunet!gatech!prism!gt0040a
  2. From: gt0040a@prism.gatech.EDU (Tom Sorensen)
  3. Newsgroups: comp.compression
  4. Subject: PKZip 2.04C bug list, #4
  5. Keywords: PKZip, bug
  6. Message-ID: <81710@hydra.gatech.EDU>
  7. Date: 25 Jan 93 17:29:03 GMT
  8. Organization: Georgia Institute of Technology
  9. Lines: 171
  10.  
  11.  
  12. I am keeping a listing of the known PKZip 2.04C bugs and posting them as
  13. I find out about them. In order to keep things simple all information is
  14. posted at one time- both old and new info is in this file. As new bugs
  15. come up they'll be added to the beginning of the file. I've also created
  16. a list of common complaints by users.
  17.  
  18. This is revision 4. New info is marked by a *. Changed info is marked by
  19. a !.
  20.  
  21. Clearly despite the one year delay not all the bugs got squashed. Note
  22. that not all bugs will be experienced by all users. Most are *HIGHLY*
  23. machine and configuration dependant.
  24.  
  25. As of 1/11/93 at 5:00 pm EST PKWare is working on a bug fix for 2.04C.
  26. It is at internal beta stage. The disk spanning, volume label, and
  27. EMS/XMS/DPMI problems are to be solved. The manual should also be fixed.
  28.  
  29. PKZip 2.04C bugs:
  30.  
  31. * PKCFG.EXE (which comes with the registered product) produces an
  32. incorrect CFG file if you want maximum compression. Instead of
  33. COMPRESS=MAXIMUM it puts COMPRESS=MAXIMAL (which is also "misprinted" in
  34. the manual).
  35.  
  36. * When viewing multiple disk archives you must do the view on the LAST
  37. disk. Viewing the first disk results in a prompt for the last disk.
  38. Viewing "middle" disks results in a perpetually spinning disk drive.
  39.  
  40. * Having ZIPFILE=latest in PKZIP.CFG and -& on the commandline causes
  41. PKZIP to come up with the help screen. -o- does not help.
  42.  
  43. Note to SYSOPs: make sure you do not have -x in your PKZIP/UNZIP
  44. strings. Doing so will cause the PKZip help screen to appear,
  45. effectively hanging your system.
  46.  
  47. ! Lines regarding XMS in PKZIP.CFG are ignored. Only the command line
  48. switch -- works. Additionally EMS=disabled disables *BOTH* EMS and XMS.
  49.  
  50. Under Novell Netware Lite PKZIP does not erase temporary files.
  51.  
  52. Having EMS enabled can cause CRC errors and trashing of QWK packets
  53. on some machines. This seems to be most prevalent under EZ-Reader v1.39.
  54.  
  55. Another manual error: the -o switch sets the ZIP date to the LATEST
  56. file, not the oldest. Online help states it correctly.
  57.  
  58. ! When you create a ZIP with directories in it 0-byte files with the
  59. names of the directories are stored inside the ZIP. These "files" can
  60. later be deleted with no damage to functionality. A collateral effect is
  61. an incorrect file count when the ZIP file is viewed.
  62.  
  63. Older versions of Norton Anti-Virus report that PKZ204C has a mutant
  64. strain of the Malaysian Amoeba Virus. This is a false positive- PKZ204C
  65. is clean. (Note this info is quite old, but just didn't get onto this
  66. list until now)
  67.  
  68. ! The AV (Authenticity Verification) was compromised a few hours after
  69. release. I HAVE confirmed this- I have exchanged several e-mail messages
  70. on the Internet with the person who broke the AV. I will not divulge the
  71. method (since he doesn't want it public knowledge, and I assume PKWare
  72. doesn't either) but it only affects pre-AV'd files and does NOT generate
  73. new AVs. Still, this means that a supposably secure ZIP file really has
  74. no protection- files inside the ZIP may be modified and still leave the
  75. AV intact. As of Monday, 1/18/93 at aprox. 2:00pm EST PKWare was
  76. ignoring the problem. Please contact them and tell them that ignoring
  77. *ANY* potential security violation regarding AVs is *NOT* acceptable.
  78. The method the programmer used is actually rather simplistic and easily
  79. implemented.
  80.  
  81. ! Several users have reported their FAT being trashed after using PKZip.
  82. I have also had some reports of the CMOS being wiped or otherwise
  83. changed. This seems to be related to DPMI usage- the faulty DPMI
  84. implementation can cause severe memory corruption which can lead to the
  85. above problems. If anyone can give me the above info please tell me.
  86.  
  87. ! Using -&f can cause problems. Bad sectors on the floppies will be
  88. unmarked and used, causing later data loss. Other users have reported
  89. that using -&f will corrupt the floppies FAT, rendering it unusable.
  90. PKZip still tries to use it though. (This occurs w/ previously formatted
  91. disks)
  92.  
  93. The multi-disk spanning ability of PKZip is highly unreliable. PKZip
  94. will report false CRC errors if any single file spans a disk (ie- if you
  95. are zipping up several files, and the 5th file must be split between the
  96. two disks, false CRC errors will be reported). A later PKZip -t reports
  97. the ZIP to be fine. Other reports of problems have been reported. It is
  98. not suggested that you use PKZip to back up your HD.
  99.  
  100. PKZip may report CRC errors if you are unzipping a file that has its
  101. path stored (-rp) and the file already exists. There are no CRC errors
  102. if the file does not exist.
  103.  
  104. ! DPMI support causes machines to crash. This occurs under QEMM, Windows,
  105. and OS/2. PKWare suggests that all users use -) to disable DPMI support
  106. at all times. OS/2 users may also disable DPMI support and/or eliminate
  107. DPMI memory from DOS sessions. In most cases there are no problems under
  108. 386Max, QEMM's 1.01 DPMI revision, or w/ DPMI_DOS_API set to ENABLED
  109. under OS/2.
  110.  
  111. Using PKZip & PKUnzip in a batch file can cause erroneous CRC errors and
  112. prompts for "Insert disk 1 in drive A:". Cause is unknown. The exact
  113. same commands work fine if executed from the command-line.
  114.  
  115. The manual is both incorrect and confusing in places. Specifically, on
  116. pages 76 and 77 of the manual:
  117.  
  118. COMPRESS=MAXIMAL
  119. should be
  120. COMPRESS=MAXIMUM
  121.  
  122. Also, the usage of the EMS, XMS, and DPMI settings are unclear. In the
  123. table they are shown as enable/disable, but in the examples on/off is
  124. used. The correct usage is enable/disable.
  125. ---------------------------------------------------------------------------
  126. Complaints. The following are a list of common complaints about the new
  127. version. Some users consider them bugs while others consider them
  128. features. In all cases, please let PKWare know how you feel on the
  129. issues.
  130.  
  131. * Some users have complained that PKZIP can't create compressed archives
  132. extractable by PKUNZIP 1.10.
  133.  
  134. * PKZIP and PKUNZIP handle command-line parameters differently. PKUNZIP
  135. doesn't care about order- -)+ means disable *BOTH* DPMI and EMS usage.
  136. PKZIP, on the other hand, IS order dependant. -)+ means enable DPMI.
  137. -+) gets identical results to PKUNZIP. This inconsistancy only further
  138. confuses users and makes no sense.
  139.  
  140. PKZIP and PKUNZIP currently have completely separate methods of
  141. configuration. PKZIP uses a CFG file while PKUNZIP uses an environment
  142. variable. Some users have commented that this doesn't make sense- both
  143. should use the configuration file. Either can easily ignore directives
  144. that do not apply.
  145.  
  146. The multi-disk spanning function is feature poor. Many users want the
  147. ability to create the files on a non-removable media for uploading or
  148. other functions. In other words, do it like ARJ does.
  149.  
  150. ! When using the -m switch with -r subdirectories are deleted along with
  151. the files. This behavior is different from the 1.10 behavior and has
  152. disgruntled several users. In particular, it causes problems for BBS
  153. SYSOPs who expect temporary directories to still be there afterwards.
  154.  
  155. Several users have complained that the PKZ204C does not report older AV
  156. stamps. This is due to the old AV being compromised. PKWare's official
  157. stance is that due to this security break 204C should *NOT* report 1.10
  158. AVs.
  159. ---------------------------------------------------------------------------
  160. I would like to thank everyone who has contributed to this list, and
  161. there are too many to mention specifically. Keep the good work up and
  162. hope PKWare kills these bugs soon!
  163.  
  164. This list is posted to ILink PKWare and Shareware conferences, the RIME
  165. PKWare conference, and comp.compression. If you feel that this list
  166. would be of use to others please feel free to post it. In particular I
  167. would like to see it distributed onto Fidonet and other networks. My
  168. only request is that this message be posted in its entirety, including
  169. headers and footers. The contact information is most important. You may
  170. delete the tagline though! <grin>
  171.  
  172. If you have any more reports or can give substantiation on some of the
  173. bugs (batch, FAT problems, AV code) please contact me. I am available on
  174. ILink PKZip, RIME PKZip, and Internet in comp.compression or e-mail at
  175. gt0040a@prism.gatech.edu.
  176.     Tom Sorensen
  177. -- 
  178. ---------------------------------------------------------------------------
  179. Tom Sorensen              gt0040a@prism.gatech.edu
  180. "I believe OS/2 is destined to be the most important operating system,
  181. and possibly program, of all time." - Bill Gates, November, 1987
  182.