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 <report@bugs.python.org>
wrote:

>
> Thomas Kluyver <thomas@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 <report@bugs.python.org>
> <https://bugs.python.org/issue22102>
> _______________________________________
>