Title: ZipFile.writestr writes incorrect extended local headers
Type: behavior Stage: test needed
Components: Library (Lib) Versions: Python 3.5, Python 3.4, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: ajaksu2, alanmcintyre, amaury.forgeotdarc, asak, serhiy.storchaka, zach.ware
Priority: normal Keywords:

Created on 2007-06-23 19:07 by asak, last changed 2014-08-19 10:05 by serhiy.storchaka.

File name Uploaded Description Edit asak, 2007-06-23 19:07 zip -T complaining about an archive
Messages (4)
msg32385 - (view) Author: alexis (asak) Date: 2007-06-23 19:07
According to 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 tells me:

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

zip error: Zip file structure invalid (

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.
msg85629 - (view) Author: Daniel Diniz (ajaksu2) Date: 2009-04-06 10:00
Confirmed for trunk and py3k.
msg85670 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-04-06 21:37
This header is optional. From

      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

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.
msg225525 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-08-19 10:05
For now zip -T doesn't complain.
Date User Action Args
2014-08-19 10:05:53serhiy.storchakasetassignee: serhiy.storchaka

messages: + msg225525
nosy: + serhiy.storchaka
2014-06-22 15:29:59zach.waresetnosy: + zach.ware
2014-06-22 15:26:25zach.waresetversions: + Python 3.4, Python 3.5, - Python 3.1, Python 3.2
2010-09-17 17:49:15BreamoreBoysetnosy: + alanmcintyre

versions: + Python 3.2
2009-04-06 21:37:53amaury.forgeotdarcsetnosy: + amaury.forgeotdarc

messages: + msg85670
versions: + Python 3.1, Python 2.7, - Python 2.6, Python 3.0
2009-04-06 10:00:49ajaksu2setversions: + Python 2.6, Python 3.0
nosy: + ajaksu2

messages: + msg85629

type: behavior
stage: test needed
2007-06-23 19:07:40asakcreate