Add file to zip, or replace file in zip

[abcd]

I have a script which zips up a directory, once it does with that
(before it closes the zip file) I want to replace a file that was added
to the zip, say "Foo.txt".

So I tried this...

z = zipfile.ZipFile("blah.zip", "w")
# zip the directory
#...
z.writestr("c:\\path\\to\\current\\foo_txt_file\\Foo.txt", "some new
data")
z.close()

All this does is add a new Foo.txt file in the zip alongside the
existing one....any suggestions?

Thanks

 

[Roger Miller]

First note that zipfile is a plain Python module, so reading
Python.../Lib/zipfile.py will reveal all its secrets.

I don't think it is possible to replace archive members using the
module. You could copy all the files into a new zip file, replacing the
ones you want to change as you go. But it might be easier just to use
os.system() or something similar to run an external zip program.

 

[Scott David Daniels]

First note that zipfile is a plain Python module, so reading
Python.../Lib/zipfile.py will reveal all its secrets.

I don't think it is possible to replace archive members using the
module. You could copy all the files into a new zip file, replacing the
ones you want to change as you go. But it might be easier just to use
os.system() or something similar to run an external zip program.

It is not currently possible to delete or replace individual elements
in a zip file, nor (in all likelihood) would you want to do so. It
would require having the zip[ file in a broken state for some time
as you copy data from one area of the zip to another. Any error
(or raised exception like Control-C) during this process is likely
to leave you with an inconsistent and therefore unreadable zip file.
The typical technique is to mark some files "deleted" in the directory,
add new files (possibly the replacements for the deleted files), and,
in one pass, copy all non-deleted files to a new zip (which you can then
swap for the original zip). Shortcutting this process puts all data in
your zip file at risk.

--Scott David Daniels
(e-mail address removed)

 

[Edward Elliott]

It is not currently possible to delete or replace individual elements
in a zip file, nor (in all likelihood) would you want to do so. It
would require having the zip[ file in a broken state for some time
as you copy data from one area of the zip to another.

If zips just used sequential access like tar files, you could append newer
versions without a problem. You windows kids and your crazy data formats.

Any error
(or raised exception like Control-C) during this process is likely
to leave you with an inconsistent and therefore unreadable zip file.

Isn't that true of any modifications to the zip archive, e.g. appending a
new file rather than replacing an existing one?

in one pass, copy all non-deleted files to a new zip (which you can then
swap for the original zip). Shortcutting this process puts all data in
your zip file at risk.

Again, isn't this true of any substantive change to any file whatsoever?
Errors during write can always leave your data in an inconsistent state,
unless your data uses a structured append format like journaled
filesystems. That seems like an orthogonal issue to replacing a file in
the archive.

 

[Scott David Daniels]

> ... You windows kids and your crazy data formats.

There were a few oth OS's than Linux and Windows. Maybe you
should call me "you crazy Tenex kid." Knuth says, "the fastest
way to search is to know where to go." -- Zips have locations of
files, and you needn't read in a lot of a huge zip to find and
extract a couple of files.

Isn't that true of any modifications to the zip archive, e.g. appending a
new file rather than replacing an existing one?

Nope. There is enough info in the zip to rebuild the directory
with a forward scan of the zip. (Each entry has a file descr).
"appending" is really replacing backing up before the zip archive
directory and writing another entry, followed by a new directory.

Again, isn't this true of any substantive change to any file whatsoever?
Errors during write can always leave your data in an inconsistent state,
unless your data uses a structured append format like journaled
filesystems. That seems like an orthogonal issue to replacing a file in
the archive.

--Scott David Daniels
(e-mail address removed)

 

[Edward Elliott]

There were a few oth OS's than Linux and Windows. Maybe you
should call me "you crazy Tenex kid."

Windows popularized the zip format, but if you insist:
You crazy Tenex kids, with your char-at-a-time raw password checking and
new-fangled virtual memory. Back in my day, all we had was Multics and we
liked it that way.

Despite having no memory prior to the Apple II, I do know a bit of history.

Knuth says, "the fastest
way to search is to know where to go." -- Zips have locations of
files, and you needn't read in a lot of a huge zip to find and
extract a couple of files.

You whippersnappers and your random access, always in such a hurry to get
your data. You want faster search, just wait a few machine generations.

 

[Scott David Daniels]

Windows popularized the zip format, but if you insist:
You crazy Tenex kids, with your char-at-a-time raw password checking and
new-fangled virtual memory. Back in my day, all we had was Multics and we
liked it that way.

Actually I think it was a combination of CP/M and DOS that popularized
the ZIP format; essentially the floppy-disk set, for whom the zip format
was a godsend.

 

[Edward Elliott]

Actually I think it was a combination of CP/M and DOS that popularized
the ZIP format; essentially the floppy-disk set, for whom the zip format
was a godsend.

Ah you're right. I just lump all Microsoft OSes under the term 'Windows'
now, though I suppose that's unfair to Xenix.