RFR JDK-8023713: ZipFileSystem has compatiable issue to handle old zip file.

[Chris Hegarty]

On 28/08/2013 00:09, Xueming Shen wrote:
> On 08/27/2013 03:07 PM, Martin Buchholz wrote:
>> It does seem vaguely reasonable to support any extra data.
>>
>> Don't you want to also handle arbitrary byte arrays, if e.g. one the
>> 16-bit size fields overflows the extra data?
>> It looks to me like getExtraLen could return a negative number.
>>
>
> probably I should. The webrev has been updated to simply
> copy the rest of the extra data, if the "sz" is either < 0 or
> out of the range.
>
> http://cr.openjdk.java.net/~sherman/8023713/webrev/

Looks ok to me Sherman.

-Chris.

>
>
>> And put a SPACE after "if".
>
> updated.
>
> Thanks!
> -Sherman
>
>>
>>
>> On Tue, Aug 27, 2013 at 2:42 PM, Xueming Shen <xueming.shen at oracle.com
>> <mailto:xueming.shen at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please help review the change for #8023713
>>
>> http://cr.openjdk.java.net/~sherman/8023713/webrev
>> <http://cr.openjdk.java.net/%7Esherman/8023713/webrev>
>>
>> The root cause is that the newly introduced ZOS.writeExtra() (for
>> #8015666) fails to handle "irregular" extra data field. The zip spec
>> requires the the extra data stars with 4 bytes of "tag + size" pair
>> and then followed by the actual "extra data". The "offending" zip
>> file actually has the "irregular" extra data field with 1 single byte
>> as the extra data. That said, the implementation (ZOS) should still
>> be able handle this kind of zip entry correctly and appropriately.
>>
>> The proposed solution is to simply copy the specified extra data
>> into the output stream.
>>
>> Thanks!
>> -Sherman
>>
>>
>