[ python-Bugs-1710703 ] zipfile.ZipFile behavior inconsistent.

[SourceForge.net]

Bugs item #1710703, was opened at 2007-05-01 11:43
Message generated for change (Comment added) made by alanmcintyre
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710703&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Flacy (markaflacy)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile.ZipFile behavior inconsistent.

Initial Comment:
In short, ZipFile() will not write the Central Directory entry unless you have added a file to it.  That makes it impossible to create a valid empty zip archive.

In one of my applications, I have the need to extract a partial set of information from one zip file and insert it into another.  There are valid use cases where the source zip archive will not have any of the files which I am looking for.  In Python 2.4, I would end up with an empty file which was considered to be a valid empty zip archive.  In Python 2.5, an empty file is not considered a valid zip archive.  

One would reasonably expect that creating a new ZipFile(mode="r") and successfully closing it without writing any entries would result in a valid zip archive that could be re-opened later without throwing an exception.



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

Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-05-09 16:40

Message:
Logged In: YES 
user_id=1115903
Originator: NO

I tried out a change to set the modified flag (_didModify) if the ZipFile
constructor ends up having mode  'w' or decides that it's appending to a
file with no existing zip structure at the end.  I'm waiting on the full
regression test suite to run against it, but it passes everything in
test_zipfile.py (and I added new tests to check for the behavior with empty
files).  I can post the patch if Mark hasn't had a chance to work one up
yet.

The docs don't seem to say anything about what happens if you open a
ZipFile in 'w' or 'a' and then just close it.  I wouldn't mind updating the
docs to cover this if desired.

As a side note, when attempting to open an empty file in 'r' mode, a
mostly unhelpful IOError (with message "invalid parameter") gets raised in
_EndRecData when attempting to seek backwards.  It seems that it would be
preferable to catch any exceptions raised by _EndRecData and raise a
BadZipFile so that it's not as cryptic.

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

Comment By: Mark Flacy (markaflacy)
Date: 2007-05-04 02:26

Message:
Logged In: YES 
user_id=1344993
Originator: YES

No wonder you're confused.  My description of how 2.4 worked was flat-out
wrong; empty files opened as zip files will throw IOExceptions and have
done so since 2.4 at least (I didn't look further back than that). 
However, it *is* the case that 2.4 would correctly write the Central
Directory entry on zipfile close for "w" and "a" modes, even for zip files
that never had any entries written into them.

In 2.4, the ZipFile.close() method contains the line...

        if self.mode in ("w", "a"):             # write ending records

...while in 2.5, the test was changed to...

        if self.mode in ("w", "a") and self._didModify: # write ending
records

That change was added in revision 46967 as part of the ZIP64 support and
that change breaks backwards compatibility (as well as not making a lot of
sense for the "w" case).

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-05-02 01:06

Message:
Logged In: YES 
user_id=33168
Originator: NO

Mark, can you create a patch for zipfile to make it do what you want?  Do
the docs mention anything about this either way?  Perhaps the docs also
need updating?

I don't know about what happened here, but I'm guessing there was some bug
fix.  This change could have been intentional or not.  I patch will help us
figure out what went wrong and how to proceed.  

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1710703&group_id=5470