Meador Inge <mead...@gmail.com> added the comment:
This is definitely *not* a padding issue.
The problem is that one of the records has an extra field of length 1:
$ zipinfo -v bla.apk
...
Central directory entry #3:
---------------------------
There are an extra 16 bytes preceding this file.
res/raw/ice.png
offset of local header from start of archive: 1190 (000004A6h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 1.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2012 Jan 13 15:30:08
32-bit CRC value (hex): f969abab
compressed size: 26250 bytes
uncompressed size: 26250 bytes
length of filename: 15 characters
length of extra field: 1 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
There is no file comment.
Our implementation can't deal with that because of the line that Terry
pointed out:
tp, ln = unpack('<HH', extra[:4])
As Martin pointed out, the standard says that things must be in
multiples of 4-bytes. So the record is non-portable.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14315>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
