prophecy 0.0.1 → 0.1.2

data/docs/licenses/zip/README

@@ -0,0 +1,234 @@
+Zip 3.0 is the first Zip update adding large file support.  For now Zip 2.3x
+remains available and supported, but users should switch to this new release.
+
+Testing for Zip 3.0 has focused mainly on Unix, VMS, Max OS X, and Win32,
+and some other ports may not be fully supported yet.  If you find your
+favorite port is broke, send us the details or, better, send bug fixes.  It's
+possible that support for some older ports may be dropped in the future.
+
+
+
+Copyright (c) 1990-2008 Info-ZIP.  All rights reserved.
+
+See the accompanying file LICENSE (the contents of which are also included
+in unzip.h, zip.h and wiz.h) for terms of use.  If, for some reason, all
+of these files are missing, the Info-ZIP license also may be found at:
+ftp://ftp.info-zip.org/pub/infozip/license.html and
+http://www.info-zip.org/pub/infozip/license.html.
+
+
+Zip 3.0 is a compression and file packaging utility.  It is compatible with
+PKZIP 2.04g (Phil Katz ZIP) for MSDOS systems.  There is a companion to zip
+called unzip (of course) which you should be able to find in the same place
+you got zip.  See the file 'WHERE' for details on ftp sites and mail
+servers.
+
+So far zip has been ported to a wide array of Unix and other mainframes,
+minis, and micros including VMS, OS/2, Minix, MSDOS, Windows, Atari, Amiga,
+BeOS and VM/CMS.  Although highly compatible with PKware's PKZIP and PKUNZIP
+utilities of MSDOS fame, our primary objective has been one of portability
+and other-than-MSDOS functionality.  Features not found in the PKWare version
+include creation of zip files in a pipe or on a device; VMS, BeOS and OS/2
+extended file attributes; conversion from Unix to MSDOS text file format; and,
+of course, the ability to run on most of your favorite operating systems.  And
+it's free.
+
+See the file zip30.ann for a summary of new features in Zip 3.0 and WhatsNew
+for the detailed list of new features and changes since Zip 2.32.  The file
+CHANGES details all day-to-day changes during development.
+
+Notes:
+
+Multi-volume support.  This version does not support multi-volume spanned
+archives as in pkzip 2.04g, and there is no intention at this point to support
+spanned archives, but Zip 3.0 supports split archives.  A split archive is an
+archive split into a set of files, each file a piece of the archive and each
+file using an extension, such as .z02 as in the file name archive.z02, that
+provides the order of the splits.  In contrast, a spanned archive is the
+original multi-floppy archive supported by pkzip 2.0g where the split order
+is contained in the volume labels.  The contents of split and spanned archives
+are mostly identical and there is a simple procedure to convert between the
+formats.  Many current unzips now support split archives.
+
+Zip64 support.  This version supports Zip64 archives as described in the
+PKWare AppNote.  These archives use additional fields to support archives
+greater than 2 GB and files in archives over the 2 GB previous limit (4 GB
+on some ports).  The Zip64 format also allows more than 64k entries in an
+archive.  Support by the OS for files larger than 4 GB is needed for Zip to
+create and read large files and archives.  On Unix, Win32, and some other
+ports, large file and Zip64 support is automatically checked for and
+compiled in if available.  Use of Zip64 by Zip is automatic and to maximize
+backward compatibility the Zip64 fields will only be used if needed.  A
+Zip64 archive requires a pkzip 4.5 compatible unzip, such as UnZip 6.0.
+
+Unicode support.  This version has initial Unicode support.  This allows
+paths and names of files in other character sets to be accurately recreated
+on OS that have sufficient character set support.  On Win32, if wide
+character calls are supported (not Win 9x unless Unicode support has been
+added) all files (including paths with illegal characters in the current
+character set) should now be readable by zip.  Unicode support is provided
+using a new set of UTF-8 path and comment extra fields and a new UTF-8 bit
+for flagging when the current character set is already UTF-8.  Zip 3.0
+maintains backward compatibility with older archives and is mostly compliant
+with the new Unicode additions in the latest PKWare AppNote.  The exception
+is UTF-8 comments, which are not supported if UTF-8 is not the native
+character set, but should be fully implemented in Zip 3.1.
+
+16-bit OS support.  Though Zip 3.0 is designed to support the latest zip
+standards and modern OS, some effort has been made to maintain support
+for older and smaller systems.  If you find Zip 3.0 does not fit on or
+otherwise does not work well on a particular OS, send in the details and
+we might be able to help.
+
+Compression methods.  In addition to the standard store and deflate methods,
+Zip now can use the bzip2 compression format using the bzip2 library.  Though
+bzip2 compression generally takes longer, in many cases using bzip2 results
+in much better compression.  However, many unzips may not yet support
+bzip2 compressed entries in archives, so test your unzip first before using
+bzip2 compression.
+
+Installation.  Please read the file INSTALL for information on how to compile
+and install zip, zipsplit, zipcloak, and zipnote and please read the manual
+pages ZIP.txt, ZIPSPLIT.txt, ZIPCLOAK.txt, and ZIPNOTE.txt for information on
+how to use them.  Also, if you are using MSDOS or Windows, note that text
+files in the distribution are generally in Unix line end format (LF only)
+and Windows and DOS users will need to either convert the files as needed to
+DOS line ends (CR LF) or extract the distribution contents using unzip -a.
+
+Utilities.  At this point zipsplit, zipcloak, and zipnote should work with
+large files, but they currently do not handle split archives.  A work around
+is to use zip to convert a split archive to a single file archive and then use
+the utilities on that archive.
+
+Encryption.  This version supports standard zip encryption.  Until recently
+the encryption code was distributed separately because of the US export
+regulations but now is part of the main distribution.  See crypt.c for
+details.  Decryption can be made with unzip 5.0p1 or later, or with zipcloak.
+
+Bug reports.  All bug reports or patches should go to zip-bugs via the web
+site contact form at http://www.info-zip.org/zip-bug.html (we have discontinued
+the old email address zip-bugs@lists.wku.edu because of too much spam lately)
+and suggestions for new features can be submitted there also (although we don't
+promise to use all of them).  We also are on SourceForge at
+http://sourceforge.net/projects/infozip/ and now automatically get Bug Reports
+and Feature Requests submitted there.  In addition, a new Info-ZIP discussion
+forum is available as well.  See below.  Though bug reports can be posted there,
+we don't have automatic monitoring of all postings set up yet so you may want
+to use the web form or SoureForge for a quicker response.  A good approach may
+be to post the details on the forum so others can benefit from the posting,
+then use the web reply form to let us know you did that if you don't get a
+reply in a reasonable time.
+
+Ports.  If you're considering a port, please check in with zip-bugs FIRST,
+since the code is constantly being updated behind the scenes.  We'll
+arrange to give you access to the latest source.
+
+Discussion group.  If you'd like to keep up to date with our Zip (and companion
+UnZip utility) development, join the ranks of BETA testers, add your own
+thoughts and contributions, etc., check out the new discussion forum.  This is
+the latest offering, after the various Info-ZIP mailing-lists on
+mxserver@lists.wku.edu (courtesy of Hunter Goatley) were no longer available
+and the temporary QuickTopic discussion group for Info-ZIP issues at
+http://www.quicktopic.com/27/H/V6ZQZ54uKNL died a horrible death due to large
+amounts of spam.  The new discussion forum is now available at
+http://www.info-zip.org/board/board.pl (thanks again to Hunter Goatley) and
+can be used to discuss issues, request features, and is one place new betas
+and releases are announced.  It also is a place to post bug reports, and
+patches can be submitted as attachments.  However, we don't yet get
+automatic notification of all postings there so try one of the other methods
+if you don't get a response.  You can also post Bug Reports and Feature
+Requests at Source Forge.  However, the web site contact form remains
+available if you would rather not post on the public forums.
+
+Frequently asked questions on zip and unzip:
+
+Q. When unzipping I get an error message about "compression method 8".
+
+A. This is standard deflate, which has been around for awhile.  Please
+   get a current version of unzip.  See the file 'WHERE' for details.
+
+
+Q. How about "compression method 12"?
+
+A. Compression method 12 is bzip2 and requires a relatively modern unzip.
+   Please get the latest version of unzip.
+
+
+Q. I can't extract this zip file that I just downloaded.  I get
+   "zipfile is part of multi-disk archive" or some other message.
+
+A. Please make sure that you made the transfer in binary mode.  Check
+   in particular that your copy has exactly the same size as the original.
+   Note that the above message also may actually mean you have only part
+   of a multi-part archive.  Also note that UnZip 5.x does not and UnZip 6.0
+   probably won't have multi-disk (split) archive support.  A work around
+   is to use Zip 3.0 to convert the split archive to a single-file archive
+   then use UnZip on that archive.  As a last result, if there's something
+   readable in what you have, zip -FF should be able to recover it.
+
+
+Q. When running unzip, I get a message about "End-of-central-directory
+   signature not found".
+
+A. This usually means that your zip archive is damaged, or that you
+   have an uncompressed file with the same name in the same directory.
+   In the first case, it makes more sense to contact the person you
+   obtained the zip file from rather than the Info-ZIP software
+   developers, and to make sure that your copy is strictly identical to
+   the original.  In the second case, use "unzip zipfile.zip" instead
+   of "unzip zipfile", to let unzip know which file is the zip archive
+   you want to extract.
+
+
+Q. Why doesn't zip do <something> just like PKZIP does?
+
+A. Zip is not a PKZIP clone and is not intended to be one.  In some
+   cases we feel PKZIP does not do the right thing (e.g., not
+   including pathnames by default); in some cases the operating system
+   itself is responsible (e.g., under Unix it is the shell which
+   expands wildcards, not zip).  Info-ZIP's and PKWARE's zipfiles
+   are interchangeable, not the programs.
+
+   For example, if you are used to the following PKZIP command:
+               pkzip -rP foo *.c
+   you must use instead on Unix:
+               zip -R foo "*.c"
+   (the quotes are needed to let the shell know that it should
+    not expand the *.c argument but instead pass it on to the program,
+    but are not needed on ports that do not expand file paths like
+    MSDOS)
+
+
+Q. Can I distribute zip and unzip sources and/or executables?
+
+A. You may redistribute the latest official distributions without any
+   modification, without even asking us for permission. You can charge
+   for the cost of the media (CDROM, diskettes, etc...) and a small copying
+   fee.  If you want to distribute modified versions please contact us at
+   www.Info-ZIP.org first. You must not distribute beta versions.
+   The latest official distributions are always on ftp.Info-ZIP.org in
+   directory /pub/infozip and subdirectories and at SourceForge.
+
+
+Q. Can I use the executables of zip and unzip to distribute my software?
+
+A. Yes, so long as it is made clear in the product documentation that
+   zip or unzip are not being sold, that the source code is freely
+   available, and that there are no extra or hidden charges resulting
+   from its use by or inclusion with the commercial product.  See the
+   Info-ZIP license for more.  Here is an example of a suitable notice:
+
+     NOTE:  <Product> is packaged on this CD using Info-ZIP's compression
+     utility.  The installation program uses UnZip to read zip files from
+     the CD.  Info-ZIP's software (Zip, UnZip and related utilities) is
+     freely distributed under the Info-ZIP license and can be obtained as
+     source code or executables from various anonymous-ftp sites,
+     including ftp://ftp.info-zip.org/pub/infozip.
+
+
+Q. Can I use the source code of zip and unzip in my commercial application?
+
+A. Yes, as long as the conditions in the Info-ZIP license are met.  We
+   recommend you include in your product documentation an acknowledgment
+   and note that the original compression sources are available at
+   www.Info-ZIP.org. If you have special requirements contact us.

data/docs/licenses/zip/README.CR

@@ -0,0 +1,119 @@
+_____________________________________________________________________________
+
+  This is Info-ZIP's README.CR for zcrypt29.zip, last updated 27 March 2008.
+_____________________________________________________________________________
+
+
+The files described below contain the encryption/decryption code for Zip 2.31,
+UnZip 5.52, and WiZ 5.02 (and later).  These files are included in the main
+source distributions for all of these now, but the encryption patch is still
+available for earlier versions of these.  This file both describes the history
+of the encryption package and notes the current conditions for use.  Check
+the comments at the top of crypt.c and crypt.h for additional information.
+
+As of version 2.9, this encryption source code is copyrighted by Info-ZIP;
+see the enclosed LICENSE file for details.  Older versions remain in the pub-
+lic domain.  Zcrypt was originally written in Europe and, as of April 2000,
+can be freely distributed from the US as well as other countries.
+
+(The ability to export from the US is new and is due to a change in the Bureau
+of Export Administration's regulations, as published in Volume 65, Number
+10, of the Federal Register [14 January 2000].  Info-ZIP filed the required
+notification via e-mail on 9 April 2000; see the USexport.msg file in this
+archive.  However, as of June 2002, it can now be freely distributed in both
+source and object forms from any country, including the USA under License
+Exception TSU of the U.S. Export Administration Regulations (section 740.13(e))
+of 6 June 2002.)
+
+    LIKE ANYTHING ELSE THAT IS FREE, ZIP, UNZIP AND THEIR ASSOCIATED
+    UTILITIES ARE PROVIDED AS IS AND COME WITH NO WARRANTY OF ANY KIND,
+    EITHER EXPRESSED OR IMPLIED. IN NO EVENT WILL THE AUTHORS BE LIABLE
+    FOR ANY DAMAGES RESULTING FROM THE USE OF THIS SOFTWARE.
+
+The encryption code is a direct transcription of the algorithm from
+Roger Schlafly, described by Phil Katz in the file appnote.txt.  This
+file is distributed with the PKZIP program (even in the version without
+encryption capabilities).  Note that the encryption will probably resist
+attacks by amateurs if the password is well chosen and long enough (at 
+least 8 characters) but it will probably not resist attacks by experts.
+Paul Kocher has made available information concerning a known-plaintext
+attack for the PKWARE encryption scheme; see http://www.cryptography.com/
+for details.)  Short passwords consisting of lowercase letters only can be
+recovered in a few hours on any workstation.  But for casual cryptography
+designed to keep your mother from reading your mail, it's OK.
+
+For more serious encryption, check into PGP (Pretty Good Privacy), a
+public-key-based encryption system available from various Internet sites.
+PGP has Zip and UnZip built into it.  The most recent version at the time
+this was originally written was 6.5, although older versions were still
+widespread.  At the time of this writing there are now GPG, PGP Universal
+2.0, and various others based on OpenPGP.
+
+We are looking at adding AES strong encryption to future versions of Zip and
+UnZip.
+
+Zip 2.3x and UnZip 5.5x and later are compatible with PKZIP 2.04g.  (Thanks
+to Phil Katz for accepting our suggested minor changes to the zipfile format.)
+
+IMPORTANT NOTE:
+
+  Zip archives produced by Zip 2.0 or later must not be *updated* by
+  Zip 1.1 or PKZIP 1.10 or PKZIP 1.93a, if they contain encrypted members
+  or if they have been produced in a pipe or on a non-seekable device.
+  The old versions of Zip or PKZIP would destroy the zip structure.  The
+  old versions can list the contents of the zipfile but cannot extract
+  it anyway (because of the new compression algorithm).  If you do not
+  use encryption and compress regular disk files, you need not worry about
+  this problem.
+
+
+Contents that were distributed and now are part of the main source files:
+
+  file           what it is
+  ----           ----------
+  README.CR      this file
+  LICENSE        Info-ZIP license (terms of reuse and redistribution)
+  USexport.msg   export notice sent to US Bureau of Export Administration
+  WHERE          where Zip/UnZip/WiZ and related utilities can be found
+  crypt.c        code for encryption and decryption
+  crypt.h        code for encryption and decryption
+  file_id.diz    description file for some BBSes
+
+Most all of the files are in Unix (LF only) format.  On MSDOS systems, you
+can use the -a option of UnZip to convert the source files to CRLF
+format.  This is only necessary if you wish to edit the files -- they
+will compile as is with Microsoft C and Turbo/Borland C++ 1.0 or
+later.  However, you will have to convert the files (using "unzip -a")
+to the CRLF format to compile with the older Turbo C 1.0 or 2.0.  You
+should be able to find Zip and UnZip in the same place you found this 
+(see ftp://ftp.info-zip.org/pub/infozip/Info-ZIP.html or the file
+"WHERE" for details).
+
+Current releases all have encryption built in.  To update previous versions
+using the zcrypt sources:
+
+  (1) Get the main sources (e.g., Zip 2.3) and unpack into a working
+      directory, as usual.
+
+  (2) Overwrite the dummy crypt.c and crypt.h from the main sources with 
+      the versions from this package.  If you want to overwrite directly
+      out of the zcrypt29 archive, do not use UnZip's freshen/updating
+      option; the dummy files may be newer than the real sources in
+      zcrypt29.  ("unzip -o zcrypt29 -d /your/working/dir" will do the
+      Right Thing in most cases, although it may overwrite a newer WHERE
+      file under some circumstances.)
+
+  (3) Read the main INSTALL document and compile normally!  No makefile
+      changes are necessary on account of the zcrypt sources.  You can
+      check that the version you just compiled has encryption or decryption
+      support enabled by typing "zip -v" or "unzip -v" and verifying that
+      the last "special compilation option" says encryption or decryption
+      is included.
+
+Encryption enables new "-e" and "-P password" options in Zip, and a new
+"-P password" option in UnZip--see the normal Zip and UnZip documentation
+for details.  (Note that passing a plaintext password on the command line
+is potentially much more insecure than being prompted for it interactively,
+which is the default for UnZip and for Zip with "-e".  Also note that the
+interactive method allows UnZip to deal with archives that use different
+passwords for different files.)

data/docs/licenses/zip/WHATSNEW

@@ -0,0 +1,333 @@
+What's New
+
+Last updated 1 July 2008
+
+This file is the full list of new features and major changes for Zip 3.0
+by beta release.  See the announcement file zip30.ann for a quick summary
+of all features and changes in Zip 3.0.  Also see the file README for
+release information, INSTALL for installation procedures, and the manual
+pages zip.txt, zipsplit.txt, zipcloak.txt, and zipnote.txt for how to use
+the new features.  The file CHANGES has all the day-to-day changes made
+during development.
+
+
+Below are some of the more significant items on the list for Zip 3.1
+(see ToDo for a more complete list):
+
+- AES encryption.
+- Extended attributes for Windows, Linux, and Mac OS X.
+- Support -d@ for deleting list of files.
+- Decide if -R, -i and -x should use external rather than internal patterns.
+- Though Unicode paths have been implemented and tested, Unicode comments
+  are not yet supported (except for comments on UTF-8 native systems which
+  are supported).
+- Verbose mode -v may still need work.
+- When pattern is directory add end / automatically.
+- Add C# example for Zip 3.0 (need to be converted to new DLLs) - original
+  C# example added with note.
+- Path Prefix maybe, so entries added to an archive can have a directory
+  path string prepended to each path.
+- UNC path support maybe.
+- Support for other languages maybe.
+- Send in your suggestions.
+- ...
+
+
+MAJOR CHANGES BY BETA VERSION
+-----------------------------
+
+New things in Zip 3.0 since Zip 3.0h:
+
+- Unicode fixes.
+- Test and fix various ports as needed.
+- Update Win32 resource to support more Windows ports.
+- Add djgpp 2.x makefile that includes bzip2.
+- Add Win32 version resource to Win32 executable.
+- Bug fixes.
+- Documentation updates.
+- Package for release.
+
+
+New things in Zip 3.0h
+
+- Allow -@ and -x to work together.
+- Unicode code cleanup.
+- Allow forcing use of UTF-8 storage in standard path and comment.
+- Update symbolic link checks.
+- Add support for storing 32-bit UIDs/GIDs using new extra field.
+  Backward compatible support for the old 16-bit UID/GID extra field
+  remains if Zip is compiled on an OS that has 16-bit UID/GID
+  storage.
+- Update VMS notes.
+- Directory scan using -AS (include only files with Windows archive
+  bit set) now ignores archive bit on directories to include all files
+  with archive bit set in all directories.  Also, to avoid empty
+  directories being created, -AS now does not store directory
+  entries.
+- Add Unix IBM support.
+- Change -W to -ws to free -W for later use.
+- Fix large file support for MinGW.
+- Fix large file support for bzip2.
+- Fix compile error in ZipCloak when UNICODE_SUPPORT is not enabled.
+- Fix Unicode bug in ZipCloak involving Unicode paths.
+- Long Unicode escapes changed from #Lxxxxxxxx to #Lxxxxxx to shorten
+  paths with escaped Unicode.
+- Bug fixes.
+
+
+New things in Zip 3.0g
+
+- Add split support to VB project for Zip64.
+- Disable reading of Unix FIFOs unless new -FI option used to avoid an
+  archiving operation stopping when it hits an active unfed FIFO.
+- The "[list]" wildcard expression (regular expression matching of any
+  character or range of characters in list) is now disabled on DOS and
+  Windows as it has caused confusion when filenames have [ and ] in
+  them.  The new -RE option reenables it.
+- Add negation to many display options such as -dc and -db.
+- Allow -FF to read and fix archives having local entries that appear
+  after central directory entries.
+- Bug fixes.
+
+
+New things in Zip 3.0f
+
+- bzip2 - The bzip2 compression method looks supported for at least
+  Windows, Unix, and VMS using the bzip2 library.  A new option, -Z cm,
+  selects the compression method.
+
+- Split archives - Can now use -s to create a split archive.  The
+  default is to update split files as the archive is being written,
+  which requires all splits to remain open until the archive is done.
+  This should be no problem when writing the archive to a hard drive,
+  for example, and this approach creates archives that should be
+  supported by all unzips that support splits.  Adding the -sp option
+  enables split pause mode that instead writes splits that do not
+  need updating and pauses Zip after each split.  This allows splits
+  to be written directly to removable media, however -sp archives
+  may not be as universally compatible.
+
+- Unicode support - Zip now stores Unicode paths that should be more
+  portable across character sets and languages.  The unzip must have
+  Unicode support enabled or the Unicode paths are ignored.  If
+  reading an archive with Unicode paths, unsupported characters are
+  replaced by #Uxxxx and #Lxxxxxxxx escapes in the file name.  Option
+  -UN controls how Unicode is handled.  Also, on systems where the
+  current character set is UTF-8, preliminary support for the new
+  General Purpose Bit Flag, bit 11, UTF-8 flag, that indicates UTF-8
+  is stored in the path and comment fields is implemented for paths.
+- Unicode on Win32 - On WIN32 systems that support the wide character
+  calls (mainly NT and later systems using NTFS), when UNICODE SUPPORT
+  is enabled Zip will now do directory scans using Unicode and convert
+  the Unicode paths to the local character set for storage in the standard
+  path field and store UTF-8 in the Unicode extra field.  This allows
+  directory scans to complete successfully regardless of the character
+  set the path is in.  On Win9x systems wide character scans are not
+  generally supported and Zip automatically uses a local character scan
+  instead.
+
+- Keep extra fields option - The default operation has been, and continues
+  to be, to read then strip old extra fields when reading entries from an
+  existing archive and then recreate the extra fields that Zip knows about.
+  Extra fields specific to each operating system get added by default also.
+  The new option -X- (negated -X) keeps any old extra fields, copying
+  them to the updated archive unchanged (unless Zip has updated them).
+  The unnegated -X still strips most all extra fields except Zip64,
+  Unicode, and UT time.
+
+- License - minor updates to the license.
+
+- Windows OEM - When compiled with WIN32_OEM (the default for WIN32),
+  Zip on WIN32 now stores OEM paths, which should be more compatible
+  with other zips and should fix some character set problems.
+- Windows Archive Bit support - On Windows can now use new -AS
+  (include if archive bit set) option to select files with the DOS
+  archive bit set and use new -AC (clear archive bits) option to clear
+  the archive bits on files after the archive has been created.
+  But -DF is probably better.
+
+- Difference mode - A new option -DF (--dif) creates an output archive
+  that includes only files changed or new since the input archive was
+  created.  Can use to create incremental backups.
+- File Sync - The new option -FS enables File Sync, a new mode that
+  synchronizes the entries in an archive with the files on the file
+  system, adding updating, and deleting entries as needed.  This
+  should create the same results as creating a new archive, but
+  since existing entries are copied, may be much faster.
+
+- Copy Mode - A new --out option allows creating a new archive with a
+  different name than the input archive, leaving the input archive
+  unchanged.  This allows updating split archives.  It also allows
+  for a new copy mode to select entries in one archive and copy them
+  directly to a new archive.
+- Empty archives - Now an empty archive is created when -i or -i@ is used
+  and the file patterns given do not match anything.  This has been
+  requested to support scripts.
+
+- Global dots - A new -dg option now displays progress dots as -dd does,
+  but instead of displaying them for each file, the dots track the total
+  bytes read for the archive.  The -dg option also works when -q is used
+  to disable most output, which allows for something like zip -qdgds 100m
+  to be used to not display specific files but display a dot every 100 MB
+  as a global status.
+- Date range - Can now use -t and -tt to set a date range
+- Fix options - Option -F redone and can recover files from an archive
+  with a mostly complete central directory more reliably, but no longer
+  can handle truncated archives.  Option -FF redone and now can salvage
+  files from slightly more damaged archives, including truncated archives.
+  In some ways -F is less powerful but more stable than it was and -FF will
+  be needed where -F in Zip 2.32 was enough.  One big change is -F and -FF
+  both now support split archives.
+- Console writing - Updates to how messages are written to the console have
+  been made including more consistent handling of line breaks.
+- Show Files options - Option -sf lists the files that would be operated
+  on.  This option can be used alone to list the files in an archive.
+  Also see options -su and -sU for showing Unicode paths.
+- UnZip Check - Now check that UnZip 6.00 or later is being used for
+  unzip if testing a Zip64 archive.  A new option -TT can be used to set
+  the unzip to use with the -T check.  Currently UnZip does not support
+  split archives so split archives can't be tested by UnZip.
+- Streaming - Directories are now handled better when streaming.
+- Case matching - Normally all matching against archive entries is case
+  sensitive, so *.BAR will not match or find foo.bar in an archive
+  when deleting, copying, or freshening entries (deleting and copying
+  only on VMS).  New option -ic (--ignore-case) enables case insensitive
+  matching.  Currently -ic is only implemented on WIN32 and VMS.
+
+- Delete date bug fixed - Bug when using -d to delete files while
+  using -t or -tt to select the files based on date is fixed
+- Large file encryption bug fixed - Fix for bug that very rarely
+  results in bad data being stored when deflating and encrypting
+  uncompressable data and resulting in CRC errors when extracting,
+  but the chance of error increases with file size (thanks to
+  WinZip for finding this bug).  See CHANGES for details.
+
+
+New things in Zip 3.0e
+
+- Bugs described in Debian patches 004 (unix configure script update) and
+  005 (large path bug) fixed
+- Various fixes
+- Add optional running stats and also end stats if not all files could
+  be read
+- Options -l and -ll now do quick binary check on first buffer and skip
+  formatting if first buffer has binary - still check at end to note
+  if formatting was done on file that was later determined to be binary,
+  but now potential file corruption is generally avoided
+- Main binary check now uses new algorithm that should also treat UTF-8 and
+  other similar encodings as text, allowing proper line end translation
+  for UTF-8 files
+- When output is not updatable by seeking back and Zip64 is enabled, output
+  is forced to Zip64 to avoid possible later need for Zip64 when not enabled
+- More work on splits, but still not usable
+- Fixes for djgpp
+- Add log file capability to save all errors and optionally messages
+- Add code to test for a Zip64 archive when compiled without Zip64 support
+- New VC6 projects for Win32 and WinDLL
+- Updates to extended help
+- Changes to force-zip64 option
+- ZE_BIG error now given also for files too big to read or write
+- Fix file delete bug
+- Update license
+- Update export documentation
+- Add VMS extended filename support
+- Add directory traversal improvements, some for Win32 ports and some for
+  all ports, that can result in a 10 times increase in speed in some cases
+
+
+New things in Zip 3.0d
+
+- Some large file crypt fixes
+- Some updates to support WiZ
+- On VMS, changed -V (/VMS) processing to truncate file at EOF, allowing
+  greater compatability with non-VMS systems.  New -VV (/VMS=ALL) option
+  saves all allocated blocks in a file.  (Previously, -V did neither.)
+- On VMS, pushed 2GB file size limit with -V out to 4GB
+- On VMS (recent, non-VAX), with SET PROCESS /PARSE = EXTEND,
+  command-line case is preserved.  This obviates quoting upper-case
+  options, like -V, when enabled
+- On VMS, fixed problems with mixed-case directory names.  Also changed
+  to keep ODS5 extended file name escape characters ("^") out of the
+  archived names in simple cases
+- Changes to the display dots
+- Option -W should now force wildcard matching to not cross directory
+  separators.  For example, a/b*r/d will match a/bar/d but not a/ba/r/d
+- Option -nw should turn off all wildcard matching so foo[bar] is matched
+  literally and [bar] is not considered a regular expression
+- Atheos port
+- Debugging of Unix and VMS large file ports.  Most features may work now
+  on these ports for large files.  Still need to fix 2 GB to 4 GB when not
+  compiled with large file support
+- On VMS, added an open callback function which (where supported) senses
+  the process RMS_DEFAULT values for file extend quantity (deq)
+  multi-block count (mbc), and multi-buffer count (mbf), and sets the
+  FAB/RAB parameters accordingly.  The default deq is now much larger
+  than before (16384 blocks, was none), and the default mbc is now 127
+  (up from 64), speeding creation of a large archive file.  The "-v"
+  option shows some of the activity.  On old VMS versions, RMS_DEFAULT
+  sensing (GETJPI) fails (silently, without "-v"), and no changes will
+  be made.  Even there, (DCL) SET RMS /EXTEND = <big> can help
+  performance.  RMS_DEFAULT values override built-in default values.
+
+
+New things in Zip 3.0c
+
+- Converted to using 64-bit file environment instead of transitional functions
+  like fseeko64 for ports that support it
+- Added "--" argument to read all following arguments as paths
+- Second help page added
+- Binary detection adjusted from 20% binary is binary to 2%
+- When -R and -i used together now -i has precedence over -R
+- Archive names with spaces can now be tested on MSDOS and Win32
+
+
+New things in Zip 3.0b
+
+- Fixed ifdefs so can test base code by compiling with NO_LARGE_FILE_SUPPORT, then
+  compiling with NO_ZIP64_SUPPORT to test 64-bit file calls (if port enables) but
+  otherwise use base code, and compiling normally to enable Zip64 code
+- Unix Zip64 fixes - should now be able to create and read large files
+- WinDLL changes to support Zip64.  Zip 3.0 dll named Zip32z64.dll
+- New VB example to show use of Zip32z64.dll
+- New options -sc (show final command line and exit) and -sd (show each
+  step zip is doing, a little different than verbose which is still there) added
+  to help debug but both or at least -sd might go away in the release
+- Some minor posted bugs fixed (see Changes)
+
+
+New things in Zip 3.0a
+
+- Initial Zip64 support allowing large files and large numbers of files
+- New command line processor
+- Other changes, see file Changes
+
+
+Note:  Zip 2.4 was never released.  That code was the start of the Zip 3.0
+effort above.
+
+
+New things in Zip 2.3
+
+- IBM OS/390 port (Unix like, but EBCDIC) by Paul von Behren
+- Apple Macintosh (MACOS) port by Dirk Haase
+- Theos port by Jean-Michel Dubois
+- Multibyte characterset support by Yoshioka Tsuneo
+- Support for ISO 8601 date format with -t and -tt options
+- Info-ZIP license
+
+
+New things in Zip 2.2
+
+- BEOS port by Chris Herborth
+- QDOS port by Jonathan Hudson
+- TANDEM port by Dave Smith
+- WINDLL port (16-bit Win 3.x and 32-bit WinNT/Win95) by Mike White
+- SYSV packages support by John Bush
+- zip -P SeCrEt encrypts entries in the zip file with password SeCrEt
+  (WARNING: THIS IS INSECURE, use at your own risk)
+- zip -R recurses into subdirectories of current dir like "PKZIP -rP"
+- zip -x@exclude.lst excludes files specified in the file exclude.lst
+- zip -i@include.lst includes files specified in the file include.lst
+- zip -@ only handles one filename per line, but supports whitespace in names
+- zip -t mmddyyyy, 4 digit year number for uniqueness of years beyond 2000
+- zip -tt mmddyyyy only includes files before a specified date