using ZipFile library with Python 2.6 or an earlier version creates
archived files that are not compatible with windows compress or Winzip.
Other programs like 7-Zip will not have a problem with the format. 

Bug Description:
if it is attempted to create an archive with more than 65535 (e.g 2^16 +
10)  files winzip or windows compress will show only what is above 65535
(in this case 9 file) 

The attached script tries to create an archive with 2^16 + 1 files and
compress or winzip will show an empty archive.

An archive with more than 65535 files must use the "64-bit extensions"
of the standard Zip format.

Such archives cannot be opened by programs that do not understand these
extensions. See http://www.winzip.com/wzdic.htm

Which version of Winzip did you try?

The version I used should not have this limitation as archives created
with other languages as Java or C# opens fine in WinZip 11.2 evaluation
version. Also the same issue can be observed in Windows compress utility.

Right, this is a bug in zipfile.py.
The official PKZIP specifications says:
http://www.pkware.com/documents/casestudies/APPNOTE.TXT

      total number of entries in the central dir: (2 bytes)

          The total number of files in the .ZIP file. If an 
          archive is in ZIP64 format and the value in this field
          is 0xFFFF, the size will be in the corresponding 8 byte 
          zip64 end of central directory field.

Patch is attached. With it I can open the file with WinZip.

Thank you for the quick fix. I could verify that the issue is fixed in
python 2.6 when I use WinZip to open an archive with more than 2^16
files created with attached script (bug.py). However the windows native
compress utility does not seem to be able to recognize the files that
have more than 2^16 files (the error says that the archive is not
valid). However, if I try to create an archive using WinZip or 7zip with
exactly the same files, windows compress utility is able to open the
archive. The same thing would apply if I create the archive using zlib
C# library.

OK, it seems that the "central directory size" and "central directory 
offset" must contain their actual value if it can fit in a 32bit int, 
even though the spec says "If an archive is in ZIP64 format and the 
value in this field is 0xFFFFFFFF, the value is in the corresponding zip64 end of central directory field."

Attached a new patch. The file generated by bug.py seems very similar to 
one generated with WinZip, and the WindowsXP explorer can now open it.

I could verify that the patch works with both the Windows Compress
utility, WinZip and 7zip. 
Thank you!

The patch looks nearly fine. AFAICT, care must be taken to always write
a ZIP64 end-of-cd record whenever an end-of-cd field overflows; I think
this patch is missing the condition centDirSize > ZIP64_LIMIT.

Here is an updated version (zip-64k-3.patch).
Now the condition for writing a "ZIP64 end-of-archive" depends on the 
size of all three values.

Looks fine to me. Please apply.

Fixed with r68661 (trunk), r68662 (py3k), r68663 (2.6) and r68664 (3.0)

Reopening, some tests have started deterministically failing:

======================================================================
ERROR: testAbsoluteArcnames (test.test_zipfile.TestZip64InSmallFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 506, in testAbsoluteArcnames
    zipfp = zipfile.ZipFile(TESTFN2, "r", zipfile.ZIP_STORED)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 710, in __init__
    self._GetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 730, in _GetContents
    self._RealGetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 767, in _RealGetContents
    raise BadZipfile, "Bad magic number for central directory"
BadZipfile: Bad magic number for central directory

======================================================================
ERROR: testDeflated (test.test_zipfile.TestZip64InSmallFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 499, in testDeflated
    self.zipTest(f, zipfile.ZIP_DEFLATED)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 434, in zipTest
    zipfp = zipfile.ZipFile(f, "r", compression)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 710, in __init__
    self._GetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 730, in _GetContents
    self._RealGetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 767, in _RealGetContents
    raise BadZipfile, "Bad magic number for central directory"
BadZipfile: Bad magic number for central directory

======================================================================
ERROR: testStored (test.test_zipfile.TestZip64InSmallFiles)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 493, in testStored
    self.zipTest(f, zipfile.ZIP_STORED)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/test/test_zipfile.py",
line 434, in zipTest
    zipfp = zipfile.ZipFile(f, "r", compression)
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 710, in __init__
    self._GetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 730, in _GetContents
    self._RealGetContents()
  File
"/home/pybot/buildarea/trunk.klose-debian-ia64/build/Lib/zipfile.py",
line 767, in _RealGetContents
    raise BadZipfile, "Bad magic number for central directory"
BadZipfile: Bad magic number for central directory

----------------------------------------------------------------------

Oops, I did see this before, but forgot to merge the patches.

It appears that "centDirOffset == 0xffffffff" is not the correct test 
for detecting zip64 structure. From the PKZip notes, a value of 
0xffffffff does imply a zip64 format, not the other way round.

So it seems necessary to always try to read the zip64 info (the _EndRecData64 function does not fail if the format is not zip64 - is 
simply returns the previous structure)
Patch is attached, and now the test passes.

Applied the zip64-alwaystry2.patch in trunk, waiting for buildbots.

Amaury, did the buildbots verify this worked and thus this bug can be
closed?

Yes, the correction went in r68678, r68700, r68734 and r68735