Message160590
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. |
|
Date |
User |
Action |
Args |
2012-05-14 01:20:41 | meador.inge | set | recipients:
+ meador.inge, loewis, terry.reedy, mark.dickinson, alanmcintyre, eric.araujo, ubershmekel, serhiy.storchaka, pleed |
2012-05-14 01:20:41 | meador.inge | set | messageid: <1336958441.23.0.971269097314.issue14315@psf.upfronthosting.co.za> |
2012-05-14 01:20:40 | meador.inge | link | issue14315 messages |
2012-05-14 01:20:39 | meador.inge | create | |
|