According to http://www.onicos.com/staff/iz/formats/zip.html the format of an optional extended local header is:

Extended local header:
Offset   Length   Contents
  0      4 bytes  Extended Local file header signature (0x08074b50)
  4      4 bytes  CRC-32
  8      4 bytes  Compressed size
 12      4 bytes  Uncompressed size

If you call ZipFile.writestr passing a ZipInfo where flag_bits & 0x08 is true, it will try to write an extended local header, but it won't write the header signature.

Even though (on Linux) unzip doesn't complain about it, a zip -T file.zip tells me:

$ zip -T file.zip
	zip warning: extended local header not found for filename

zip error: Zip file structure invalid (file.zip)


Tested on a debian unstable system, with Python 2.3.5, 2.4.4 and 2.5.1.

I'm attaching a simple test case.

Confirmed for trunk and py3k.

This header is optional. From 
http://www.pkware.com/documents/casestudies/APPNOTE.TXT

      Although not originally assigned a signature, the value 
      0x08074b50 has commonly been adopted as a signature value 
      for the data descriptor record.  Implementers should be 
      aware that ZIP files may be encountered with or without this 
      signature marking data descriptors and should account for
      either case when reading ZIP files to ensure compatibility.
      When writing ZIP files, it is recommended to include the
      signature value marking the data descriptor record.  When
      the signature is used, the fields currently defined for
      the data descriptor record will immediately follow the
      signature.

So this is Not A Bug (and "zip -T" correctly reports a Warning)

However, I suggest to follow the recommendation and add the signature, 
for 2.7/3.1 only, and not to backport.

For now zip -T doesn't complain.