ZipFile - file adding API incomplete?

[Scott David Daniels]

Glenn Maynard wrote:
> I want to do something fairly simple: read files from one ZIP and add
> them to another, so I can remove and replace files.  This led me to a
> couple things that seem to be missing from the API.
> 
> .... zip.write() only takes the filename and
> compression method, not a ZipInfo; writestr takes a ZipInfo but only
> accepts a string, not a file.  Is there an API call I'm missing?
> (This seems like the fundamental API for adding files, that write and
> writestr should be calling.)

Simple answer: its not there in the API.

Defining that API correctly is tricky, and fraught with issues about
access to the ZipFile object (from both the same thread and from other
threads) while it is mid-modification.  Nonetheless, a carefully done
API that addresses those issues would be valuable.  If you do spend the
time to get something reliable going, put it someplace public and I
predict it will get use.

The approach I fiddled with was:
     * Define a calls to read _portions_ of the raw (compressed,
       encrypted, whatever) data.
     * Define a call that locks the ZipFile object and returns a
       write handle for a single new file.  At that point the
       new file doesn't exist, but reading of other portions of
       the zip file are allowed.
     * Only on successful close of the "write handle" is the new
       directory written.
Unfortunately, I never worked very hard at the directory entries,
and I realize that the big flaw in this design is that from the moment 
you start overwriting the existing master directory until you write
a new master at the end, your do not have a valid zip file.

Also note that you'll have to research standards about _exactly_ what
the main header should look like if you use particular features.  My
stuff did bzip compression as well, and about the "find which bits
means what" was where my process broke down.

--Scott David Daniels
Scott.Daniels at Acm.Org