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

[Xueming Shen]

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.

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


ZOS.writeCEN
        {
                writeShort(EXTID_EXTT);
                 if (e.mtime != null) {
                     writeShort(5);      // flag + mtime
                     writeByte(flagEXTT);
                     writeInt(umtime);
         } else {
                     writeShort(1);      // flag only
                     writeByte(flagEXTT);
         }

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

-Sherman