JDK-8173072: zipfs fails to handle incorrect info-zip "extended timestamp extra field"

Xueming Shen xueming.shen at oracle.com
Fri Jan 20 09:02:12 UTC 2017

On 1/20/17, 12:28 AM, Xueming Shen wrote:
> -----------------------------
>          The lower three bits of Flags in both headers indicate which 
> time-
>          stamps are present in the LOCAL extra field:
>                 bit 0           if set, modification time is present
>                 bit 1           if set, access time is present
>                 bit 2           if set, creation time is present
>                 bits 3-7        reserved for additional timestamps; 
> not set
> ------------------------------
> It means we need to fix the ZipOutputStream to output the correct cen 
> entry flags, if there
> are more extra timestamps. (jar does not create them)

False alarm, It has been years since I wrote this part of the code :-) 
Just doubt checked the code,
it appears both ZipOutputStream and zipfs.Entry.writeCEN() are 
implemented correctly to output
the correct flags that indicate the timestamps in loc only.

            if (elenEXTT != 0) {
                 writeShort(os, EXTID_EXTT);
                 writeShort(os, elenEXTT - 4);
                 if (ctime == -1)
                     os.write(0x3);          // mtime and atime
                     os.write(0x7);          // mtime, atime and ctime
                 writeInt(os, javaToUnixTime(mtime));

                 if (e.mtime != null) {
                     writeShort(5);      // flag + mtime
         } else {
                     writeShort(1);      // flag only

So the better fix for this one should simply not try to read a/ctime at all
in cen reading code.


More information about the nio-dev mailing list