gh-51067: Add remove() and repack() to ZipFile#134627
Open
danny0838 wants to merge 72 commits intopython:mainfrom
Open
gh-51067: Add remove() and repack() to ZipFile#134627danny0838 wants to merge 72 commits intopython:mainfrom
remove() and repack() to ZipFile#134627danny0838 wants to merge 72 commits intopython:mainfrom
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a revised version of PR #103033, implementing two new methods in
zipfile.ZipFile:remove()andrepack(), as suggested in this comment.Features
ZipFile.remove(zinfo_or_arcname)strpath orZipInfo) from the central directory.strpath is provided.ZipInfoinstance.'a','w','x'.ZipFile.repack(removed=None)removedis passed (as a sequence of removedZipInfos), only their corresponding local file entry data are removed.'a'.Rationales
Heuristics Used in
repack()Since
repack()does not immediately clean up removed entries at the time aremove()is called, the header information of removed file entries may be missing, and thus it can be technically difficult to determine whether certain stale bytes are really previously removed files and safe to remove.While local file entries begin with the magic signature
PK\x03\x04, this alone is not a reliable indicator. For instance, a self-extracting ZIP file may contain executable code before the actual archive, which could coincidentally include such a signature, especially if it embeds ZIP-based content.To safely reclaim space,
repack()assumes that in a normal ZIP file, local file entries are stored consecutively:BadZipFileerror is raised and no changes are made.Check the doc in the source code of
_ZipRepacker.repack()(which is internally called byZipFile.repack()) for more details.Supported Modes
There has been opinions that a repacking should support mode
'w'and'x'(e. g. #51067 (comment)).This is NOT introduced since such modes do not truncate the file at the end of writing, and won't really shrink the file size after a removal has been made. Although we do can change the behavior for the existing API, some further care has to be made because mode
'w'and'x'may be used on an unseekable file and will be broken by such change. OTOH, mode'a'is not expected to work with an unseekable file since an initial seek is made immediately when it is opened.📚 Documentation preview 📚: https://cpython-previews--134627.org.readthedocs.build/