It would be most helpful if a method could be included in the TarFile
class of the tarfile module and the ZipFile class of the zipfile module
that would remove a particular file (either given by a name or a
TarInfo/ZipInfo object) from the archive.

Usage to remove a single file from an archive would be as follows:

import zipfile
zipFileObject = zipfile.ZipFile(archiveName,'a')
zipFileObject.remove(fileToRemove)
zipFileObject.close()

Such a method should probably only apply to archives that are in append
mode as write mode would erase the original archive and read mode should
render the archive immutable.

One possible extra to be included is to allow a list of file names or
ZipInfo/TarInfo objects to be passed into the remove method, such that
all items in the list would be removed from the archive.

+1

Slight change to:

"Such a method should probably only apply to archives that are in append
mode as write mode would erase the original archive and read mode should
render the archive immutable."

The method should probably still apply to an archive in write mode.  It
is conceivable that one may need to delete a file from the archive after
it has been written but before the archive object has been closed.

-1. I don't think this can be implemented in a reasonable way, assuming
that you want the file to become smaller as a consequence of removal.

-1, although I can only speak for tarfile. Removing members from a tar
archive sounds obvious and easy but it is *not*. A file in an archive is
stored as a header block (that contains the metadata) followed by a
number of data blocks (that contain the file's data). New files are
simply appended to the archive file. There is no central table of
contents whatsoever. To make things worse, a compressed archive is
compressed in one go from the beginning right up to the end, it is not
possible to access a member in the middle of an archive without having
to decompress all data before it.
Deleting files from an uncompressed archive is rather straightforward
implementation-wise but IO intensive and risky. In contrast, there is no
other way to delete files from a *compressed* tarfile than to make a
copy of it omitting the unwanted files.

In light of Lars's comment on the matter, perhaps this functionality
could be added to zip files only.  Surely it can be done, considering
that numerous utilities and even Windows Explorer provide such
functionality.  I must confess that I am unfamiliar with the inner
workings of file archives and compression, but seeing as it is
implemented in a number of places already, it seems logical that it
could be implemented in ZipFile as well.  I'll spend some time the next
few days educating myself about zip files and how this might be
accomplished.

> In light of Lars's comment on the matter, perhaps this functionality
> could be added to zip files only.  Surely it can be done, considering
> that numerous utilities and even Windows Explorer provide such
> functionality.

Are you sure they are not creating a new file in order to delete
content? I recall that early zip tools (e.g. pkzip) had a mode
where they would merely delete the entry from the directory, but
leave the actual data in the file. Would you consider that a correct
implementation? If so, *that* can be done, for zipfiles, AFAIU.

> I'll spend some time the next
> few days educating myself about zip files and how this might be
> accomplished.

Please do - you'll find that deletion from zipfiles comes in a can
full of worms.

I done it In a very *violent* way.
Is it ok for you thought?
if so, would anybody please fix it into the lib?

> I done it In a very *violent* way.
> Is it ok for you thought?

In the form in which you have done it, it is clearly
unacceptable for inclusion in the library: we don't
want to add two modules "delete" and "classtools".

In addition, notice that code is for tarfile, whereas
the OP was asking for a similar feature for zipfile.

> if so, would anybody please fix it into the lib?

This is not how this works. If you want us to take
action, please submit a complete and correct patch.

I have attempted to implement a ZipFile.remove function.  It seems to work fine.  I have submitted a patch.

The method of implementation is: find the file's index in the file list, then sum the lengths of the file entries before it to find its location in the archive.  Then simply read in all the bytes after it, write them out at that location, and truncate the file x bytes shorter, where x is the length of the record.  This works because the directory listing is created when the file is closed, so there's no harm in truncating.

I've also made it truncate the zip file after reading in the existing files upon creation, because the directory information is not used after this point.

This could use some testing on large files.

This is my first patch, so let me know if I've done anything wrong.

My patch had some bugs, I'll need to do some more testing.  Sorry about that.

What's the status with this patch? If nobody's looking at it I can try to see if it works and write the test and documentation for it.

Please feel free to test, revise, and write. Though 'removed', the file is still accessible via the history list. (Click 'zipfile_remove.patch' and then 'download'.)

I fixed the bugs I found, added tests and documentation. What do you guys think?

Fixed the bugs Martin pointed out and added the relevant tests. Sadly I had to move some stuff around, but I think the changes are all for the better. I wasn't sure about the right convention for the 2 constants I added btw.

Martin did a review of the newer patch; maybe you didn’t get the mail (there’s a Rietveld bug when a user name without email is given to the Cc field).

I'm not sure I understand how http://bugs.python.org/review/6818/show works. I've looked all over and only found remarks for "zipfile.remove.patch" and not for "zipfile.remove.2.patch" which addressed all the aforementioned issues.

Also, I don't understand how to add myself to the CC of this issue's review page.

Yuval, can you please submit a contributor agreement? See

http://www.python.org/psf/contrib/

As for adding yourself to the CC list: notice the string "ubershmekel" appearing in the "CC" field of http://bugs.python.org/review/6818/show. It means that you are already on the CC list.