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

SourceForge.net noreply at sourceforge.net
Fri May 4 09:26:00 CEST 2007


Bugs item #1710703, was opened at 2007-05-01 11:43
Message generated for change (Comment added) made by markaflacy
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: 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


More information about the Python-bugs-list mailing list