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

Xueming Shen xueming.shen at oracle.com
Fri Jan 20 09:03:49 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