Guillaume Carre <gcarr...@gmail.com> added the comment: Hi, In my case the zip file was created from windows 7 context menu (send to) Regards, Guillaume
On Mon, Mar 12, 2018 at 5:08 AM, Thomas Kluyver <rep...@bugs.python.org> wrote: > > 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 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
