1This is the README file for the 20 April 2009 public release of the 2Info-ZIP group's portable UnZip zipfile-extraction program (and related 3utilities). 4 5unzip60.zip portable UnZip, version 6.0, source code distribution 6unzip60.tar.Z same as above, but compress'd tar format 7unzip60.tar.gz same as above, but gzip'd tar format 8 9__________________________________________________________________________ 10 11BEFORE YOU ASK: UnZip, its companion utility Zip, and related utilities 12and support files can be found in many places; read the file "WHERE" for 13further details. To contact the authors with suggestions, bug reports, 14or fixes, continue reading this file (README) and, if this is part of a 15source distribution, the file "ZipPorts" in the proginfo directory. Also 16in source distributions: read "BUGS" for a list of known bugs, non-bugs 17and possible future bugs; INSTALL for instructions on how to build UnZip; 18and "Contents" for a commented listing of all the distributed files. 19__________________________________________________________________________ 20 21 22GENERAL INFO 23------------ 24UnZip is an extraction utility for archives compressed in .zip format (also 25called "zipfiles"). Although highly compatible both with PKWARE's PKZIP 26and PKUNZIP utilities for MS-DOS and with Info-ZIP's own Zip program, our 27primary objectives have been portability and non-MSDOS functionality. 28 29This version of UnZip has been ported to a stupendous array of hardware-- 30from micros to supercomputers--and operating systems: Unix (many flavors), 31VMS, OS/2 (including DLL version), Windows NT and Windows 95 (including DLL 32version), Windows CE (GUI version), Windows 3.x (including DLL version), 33MS-DOS, AmigaDOS, Atari TOS, Acorn RISC OS, BeOS, Macintosh (GUI version), 34SMS/QDOS, MVS, VM/CMS, FlexOS, Tandem NSK, Human68k (mostly), AOS/VS (partly) 35and TOPS-20 (partly). UnZip features not found in PKUNZIP include source 36code; default extraction of directory trees (with a switch to defeat this, 37rather than the reverse); system-specific extended file attributes; and, of 38course, the ability to run under most of your favorite operating systems. 39Plus, it's free. :-) 40 41For source distributions, see the main Contents file for a list of what's 42included, and read INSTALL for instructions on compiling (including OS- 43specific comments). The individual operating systems' Contents files (for 44example, vms/Contents) may list important compilation info in addition to 45explaining what files are what, so be sure to read them. Some of the ports 46have their own, special README files, so be sure to look for those, too. 47 48See unzip.1 or unzip.txt for usage (or the corresponding UnZipSFX, ZipInfo, 49fUnZip and ZipGrep docs). For VMS, unzip_def.rnh or unzip_cli.help may be 50compiled into unzip.hlp and installed as a normal VMS help entry; see 51vms/descrip.mms. 52 53 54CHANGES AND NEW FEATURES 55------------------------ 56UnZip 6.0 finally supports nowadays "large" files of sizes > 2 GiB! 57This is the first release containing support for the PKWARE Zip64 58enhancements. 59Major changes are: 60 - Support PKWARE ZIP64 extensions, allowing Zip archives and Zip archive 61 entries larger than 4 GiBytes and more than 65536 entries within a single 62 Zip archive. This support is currently only available for Unix, 63 OpenVMS and Win32/Win64. 64 - Support for bzip2 compression method. 65 - Support for UTF-8 encoded entry names, both through PKWARE's "General 66 Purpose Flags Bit 11" indicator and Info-ZIP's new "up" unicode path 67 extra field. (Currently, on Windows the UTF-8 handling is limited to 68 the character subset contained in the configured non-unicode "system 69 code page".) 70 - Added "wrong implementation used" warning to error messages of the MSDOS 71 port when used under Win32, in an attempt to reduce false bug reports. 72 - Fixed "Time of Creation/Time of Use" vulnerability when setting attributes 73 of extracted files, for Unix and Unix-like ports. 74 - Fixed memory leak when processing invalid deflated data. 75 - Fixed long-standing bug in unshrink (partial_clear), added boundary checks 76 against invalid compressed data. 77 - On Unix, keep inherited SGID attribute bit for extracted directories 78 unless restoration of owner/group id or SUID/SGID/Tacky attributes was 79 requested. 80 - On Unix, allow extracted filenames to contain embedded control characters 81 when explicitly requested by specifying the new command line option "-^". 82 - On Unix, support restoration of symbolic link attributes. 83 - On Unix, support restoration of 32-bit UID/GID data using the new "ux" 84 IZUNIX3 extra field introduced with Zip 3.0. 85 - Support for ODS5 extended filename syntax on new OpenVMS systems. 86 - Support symbolic links zipped up on VMS. 87 - On VMS (only 8.x or better), support symbolic link creation. 88 - On VMS, support option to create converted text files in Stream_LF format. 89 - New -D option to suppress restoration of timestamps for extracted 90 directory entries (on those ports that support setting of directory 91 timestamps). By specifying "-DD", this new option also allows to suppress 92 timestamp restoration for ALL extracted files on all UnZip ports which 93 support restoration of timestamps. 94 On VMS, the default behaviour is now to skip restoration of directory 95 timestamps; here, "--D" restores ALL timestamps, "-D" restores none. 96 - On OS/2, Win32, and Unix, the (previously optional) feature UNIXBACKUP 97 to allow saving backup copies of overwritten files on extraction is now 98 enabled by default. 99 100For the UnZip 6.0 release, we want to give special credit to Myles Bennet, 101who started the job of supporting ZIP64 extensions and Large-File (> 2GiB) 102and provided a first (alpha-state) port. 103 104The 5.52 maintenance release fixes a few minor problems found in the 5.51 105release, closes some more security holes, adds a new AtheOS port, and 106contains a Win32 extra-field code cleanup that was not finished earlier. 107The most important changes are: 108 109 - (re)enabled unshrinking support by default, the LZW patents have expired 110 - fixed an extraction size bug for encrypted stored entries (12 excess bytes 111 were written with 5.51) 112 - fixed false "uncompressed size mismatch" messages when extracting 113 encrypted archive entries 114 - do not restore SUID/SGID/Tacky attribute bits on Unix (BeOS, AtheOS) 115 unless explicitely requested by new "-K" command line qualifier 116 - optional support for "-W" qualifier to modify the pattern matching syntax 117 (with -W: "*" stops at directory delimiter, "**" matches unlimited) 118 - prevent buffer overflow caused by bogus extra-long Zipfile specification 119 - performance enhancements for VMS port 120 - fixed windll interface handling of its extraction mode qualifiers 121 nfflag, ExtractOnlyNewer, noflag, PromptToOverwrite; added detailed 122 explanation of their meanings and interactions to the windll documentation 123 124The 5.51 maintenance release adds a command-line CE port, intended for 125batch processing. With the integration of this port, the pUnZip port 126has been revised and "revitalized". 127The most important changes for the general public are a number of 128bug fixes, mostly related to security issues: 129 130 - repair a serious bug in the textmode output conversion code for the 16-bit 131 ports (16-bit MSDOS, OS/2 1.x, some variants of AMIGA, possibly others) 132 which was introduced by the Deflate64 support of release 5.5 133 - fix a long standing bug in the the inflate decompression method that 134 prevented correct extraction in some rare cases 135 - fixed holes in parent dir traversal security code (e.g.: ".^C." slipped 136 through the previous version of the check code) 137 - fixed security hole: check naming consistency in local and central header 138 - fixed security hole: prevent extracted symlinks from redirecting file 139 extraction paths 140 141The main addition in the 5.5 release is support for PKWARE's new Deflate64(tm) 142algorithm, which appeared first in PKZIP 4.0 (published November 2000). 143As usual, some other bugfixes and clean-ups have been integrated: 144 145 - support for Deflate64 (Zip compression method #9) 146 - support for extracting VMS variable length record text files on 147 any system 148 - optional "cheap autorun" feature for the SFX stub 149 - security fixes: 150 * strip leading slash from stored pathspecs, 151 * remove "../" parent dir path components from extracted file names 152 - new option "-:" to allow verbatim extraction of file names containing 153 "../" parent dir path specs 154 - fixed file handle leak for the DLL code 155 - repaired OS2 & WinNT ACL extraction which was broken in 5.42 156 157The 5.42 maintenance release fixes more bugs and cleans up the redistribution 158conditions: 159 160 - removal of unreduce.c and amiga/timelib.c code to get rid of the last 161 distribution restrictions beyond the BSD-like Info-ZIP LICENSE 162 - new generic timelib replacement (currently used by AMIGA port) 163 - more reasonable mapping rules of UNIX "leading-dot" filenames to the 164 DOS 8.3 name convention 165 - repaired screensize detection in MORE paging code 166 (was broken for DOS/OS2/WIN32 in 5.41) 167 168The 5.41 maintenance release adds another new port and fixes some bugs. 169 170 - new BSD-like LICENSE 171 - new Novell Netware NLM port 172 - supports extraction of archives with more than 64k entries 173 - attribute handling of VMS port was broken in UnZip 5.4 174 - decryption support integrated in the main source distribution 175 176The 5.4 release adds new ports, again. Other important items are changes 177to the listing format, new supplemental features and several bug fixes 178(especially concerning time-stamp handling...): 179 180 - new IBM OS/390 port, a UNIX derivate (POSIX with EBCDIC charset) 181 - complete revision of the MacOS port 182 - changed listing formats to enlarge the file size fields for more digits 183 - added capability to restore directory attributes on MSDOS, OS/2, WIN32 184 - enabled support of symbolic links on BeOS 185 - Unix: optional Acorn filetype support, useful for volumes exported via NFS 186 - several changes/additions to the DLL API 187 - GUI SFX stub for Win16 (Windows 3.1) and Win32 (Windows 9x, Windows NT) 188 - new free GCC compiler environments supported on WIN32 189 - many time-zone handling bug fixes for WIN32, AMIGA, ... 190 191The 5.32 release adds two new ports and a fix for at least one relatively 192serious bug: 193 194 - new FlexOS port 195 - new Tandem NSK port 196 - new Visual BASIC support (compatibility with the Windows DLLs) 197 - new -T option (set zipfile timestamp) for virtually all ports 198 - fix for timestamps beyond 2038 (e.g., 2097; crashed under DOS/Win95/NT) 199 - fix for undetected "dangling" symbolic links (i.e., no pointee) 200 - fix for VMS indexed-file extraction problem (stored with Zip 2.0 or 2.1) 201 - further performance optimizations 202 203The 5.31 release included nothing but small bug-fixes and typo corrections, 204with the exception of some minor performance tweaks. 205 206The 5.3 release added still more ports and more cross-platform portability 207features: 208 209 - new BeOS port 210 - new SMS/QDOS port 211 - new Windows CE graphical port 212 - VM/CMS port fully updated and tested 213 - MVS port fully updated and tested 214 - updated Windows DLL port, with WiZ GUI spun off to a separate package 215 - full Universal Time (UTC or GMT) support for trans-timezone consistency 216 - cross-platform support for 8-bit characters (ISO Latin-1, OEM code pages) 217 - support for NT security descriptors (ACLs) 218 - support for overwriting OS/2 directory EAs if -o option given 219 - updated Solaris/SVR4 package facility 220 221What is (still!) not added is multi-part archive support (a.k.a. "diskette 222spanning", though we really mean archive splitting and not the old diskette 223spanning) and a unified and more powerful DLL interface. These are the two 224highest priorities for the 6.x releases. Work on the former is almost 225certain to have commenced by the time you read this. This time we mean it! 226You betcha. :-) 227 228Although the DLLs are still basically a mess, the Windows DLLs (16- and 32- 229bit) now have some documentation and a small example application. Note that 230they should now be compatible with C/C++, Visual BASIC and Delphi. Weirder 231languages (FoxBase, etc.) are probably Right Out. 232 233 234INTERNET RESOURCES 235------------------ 236 237Info-ZIP's web site is at http://www.info-zip.org/pub/infozip/ 238and contains the most up-to-date information about coming releases, 239links to binaries, and common problems. 240(See http://www.info-zip.org/pub/infozip/FAQ.html for the latter.) 241Files may also be retrieved via ftp://ftp.info-zip.org/pub/infozip/ . 242Thanks to LEO (Munich, Germany) for previously hosting our primary site. 243 244 245DISTRIBUTION 246------------ 247If you have a question regarding redistribution of Info-ZIP software, either 248as is, as packaging for a commercial product, or as an integral part of a 249commercial product, please read the Frequently Asked Questions (FAQ) section 250of the included COPYING file. All Info-ZIP releases are now covered by 251the Info-ZIP license. See the file LICENSE. The most current license 252should be available at http://www.info-zip.org/license.html and 253ftp://ftp.info-zip.org/pub/infozip/license.html. 254 255Insofar as C compilers are rare on some platforms and the authors only have 256direct access to a subset of the supported systems, others may wish to pro- 257vide ready-to-run executables for new systems. In general there is no prob- 258lem with this; we require only that such distributions include this README 259file, the WHERE file, the LICENSE file (contains copyright/redistribution 260information), and the appropriate documentation files (unzip.txt and/or 261unzip.1 for UnZip, etc.). If the local system provides a way to make self- 262extracting archives in which both the executables and text files can be 263stored together, that's best (in particular, use UnZipSFX if at all possible, 264even if it's a few kilobytes bigger than the alternatives); otherwise we 265suggest a bare UnZip executable and a separate zipfile containing the re- 266maining text and binary files. If another archiving method is in common 267use on the target system (for example, Zoo or LHa), that may also be used. 268 269 270BUGS AND NEW PORTS: CONTACTING INFO-ZIP 271---------------------------------------- 272All bug reports and patches (context diffs only, please!) should be 273submitted either through the new Info-ZIP Discussion Forum at 274http://www.info-zip.org/board/board.pl or through the Info-ZIP SourceForge 275site at http://sourceforge.net/projects/infozip/. The forum allows file 276attachments while SourceForge provides a place to post patches. The old 277Zip-Bugs@lists.wku.edu e-mail address for the Info-ZIP authors was 278discontinued after heavy continuous spam, as was the QuickTopic discussion 279forum. The above methods are public, but we also can be reached directly 280using the web reply page at http://www.info-zip.org/zip-bug.html. If you 281need to send us files privately, contact us first for instructions. 282 283"Dumb questions" that aren't adequately answered in the documentation 284should also be directed to Zip-Bugs rather than to a global forum such 285as Usenet. (Kindly make certain that your question *isn't* answered by 286the documentation, however--a great deal of effort has gone into making 287it clear and complete.) 288 289Suggestions for new features can be discussed on the new Discussion Forum. 290A new mailing list for Info-ZIP beta testers and interested parties may 291be created someday, but for now any issues found in the betas should use 292the forum. We make no promises to act on all suggestions or even all 293patches, but if it is something that is manifestly useful, sending the 294required patches to Zip-Bugs directly (as per the instructions in the 295ZipPorts file) is likely to produce a quicker response than asking us to 296do it--the authors are always ridiculously short on time. (Please do 297NOT send patches or encoded zipfiles to the Info-ZIP list. Please DO 298read the ZipPorts file before sending any large patch. It would be 299difficult to over-emphasize this point...) 300 301If you are considering a port, not only should you read the ZipPorts file, 302but also please check in with Zip-Bugs BEFORE getting started, since the 303code is constantly being updated behind the scenes. (For example, VxWorks, 304VMOS and Netware ports were once claimed to be under construction, although 305we have yet to see any up-to-date patches.) We will arrange to send you the 306latest sources. The alternative is the possibility that your hard work will 307be tucked away in a subdirectory and mostly ignored, or completely ignored 308if someone else has already done the port (and you'd be surprised how often 309this has happened). 310 311 312BETA TESTING: JOINING INFO-ZIP 313------------------------------- 314If you'd like to keep up to date with our UnZip (and companion Zip utility) 315development, join the ranks of beta testers, add your own thoughts and 316contributions, or simply lurk, you may join one of our mailing lists. 317There is an announcements-only list (Info-ZIP-announce) and a general 318discussion/testing list (Info-ZIP). You must be a subscriber to post, and 319you can subscribe via the links on our Frequently Asked Questions page: 320 321 http://www.info-zip.org/pub/infozip/FAQ.html#lists 322 323(Please note that as of late May 2004, the lists are unavailable pending 324a move to a new site; we hope to have them restored shortly. In the 325interim ...) Feel free to use our bug-reporting web page for bug reports 326and to ask questions not answered on the FAQ page above: 327 328 http://www.info-zip.org/zip-bug.html 329 330For now the best option is to monitor and contribute to the various threads 331on the new discussion forum site at: 332 333 http://www.info-zip.org/board/board.pl 334 335The second best way to contribute is through the various features at 336SourceForge, such as the bug posting areas. 337 338There is also a closed mailing list for internal discussions of our core 339development team. This list is now kept secret to prevent us from being 340flooded with spam messages. 341 342 343-- Greg Roelofs (sometimes known as Cave Newt), principal UnZip developer 344 guy, with inspiration from David Kirschbaum, was Author of this text. 345 346-- Christian Spieler (shorthand: SPC), current UnZip maintenance coordinator, 347 applied the most recent changes, with Ed Gordon providing a few additions. 348