Thomas Kluyver <tho...@kluyver.me.uk> added the comment: I found source code for some other projects handling the same data. They all seem to agree that it should be 1:
- Golang's zip reading code: https://github.com/golang/go/blob/f7ac70a56604033e2b1abc921d3f0f6afc85a7b3/src/archive/zip/reader.go#L536-L538 - A C contrib file with zlib: https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/contrib/minizip/zip.c#L620-L624 - Code from Info-ZIP, which is used by many Linux distros, is a bit less clear, but it has an illuminating comment: if ((G.ecrec.number_this_disk != 0xFFFF) && (G.ecrec.number_this_disk != ecloc64_total_disks - 1)) { /* Note: For some unknown reason, the developers at PKWARE decided to store the "zip64 total disks" value as a counter starting from 1, whereas all other "split/span volume" related fields use 0-based volume numbers. Sigh... */ So I think you've got an invalid zip file. If it's otherwise valid, there might be a case for Python tolerating that particular mistake. But it's probably better to fix whatever is making the incorrect zip file, because other tools are also going to reject it. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22102> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
