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