@@ -995,11 +995,35 @@ internal void ProcessExtraData(bool localHeader)
995995 throw new ZipException ( "Extra data extended Zip64 information length is invalid" ) ;
996996 }
997997
998- if ( localHeader || ( size == uint . MaxValue ) ) {
998+ // (localHeader ||) was deleted, because actually there is no specific difference with reading sizes between local header & central directory
999+ // https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
1000+ // ...
1001+ // 4.4 Explanation of fields
1002+ // ...
1003+ // 4.4.8 compressed size: (4 bytes)
1004+ // 4.4.9 uncompressed size: (4 bytes)
1005+ //
1006+ // The size of the file compressed (4.4.8) and uncompressed,
1007+ // (4.4.9) respectively. When a decryption header is present it
1008+ // will be placed in front of the file data and the value of the
1009+ // compressed file size will include the bytes of the decryption
1010+ // header. If bit 3 of the general purpose bit flag is set,
1011+ // these fields are set to zero in the local header and the
1012+ // correct values are put in the data descriptor and
1013+ // in the central directory. If an archive is in ZIP64 format
1014+ // and the value in this field is 0xFFFFFFFF, the size will be
1015+ // in the corresponding 8 byte ZIP64 extended information
1016+ // extra field. When encrypting the central directory, if the
1017+ // local header is not in ZIP64 format and general purpose bit
1018+ // flag 13 is set indicating masking, the value stored for the
1019+ // uncompressed size in the Local Header will be zero.
1020+ //
1021+ // Othewise there is problem with minizip implementation
1022+ if ( size == uint . MaxValue ) {
9991023 size = ( ulong ) extraData . ReadLong ( ) ;
10001024 }
10011025
1002- if ( localHeader || ( compressedSize == uint . MaxValue ) ) {
1026+ if ( compressedSize == uint . MaxValue ) {
10031027 compressedSize = ( ulong ) extraData . ReadLong ( ) ;
10041028 }
10051029
0 commit comments