RFR JDK-8206389: JarEntry.setCreation/LastAccessTime without setLastModifiedTime causes Invalid CEN header

[Martin Buchholz]

I would use different timestamps for the 4 possible times used in this
test, if only to make it clearer which value comes from where.

+            // ze.setLastModifiedTime(now);+
ze.setTime(now.toMillis());


setTime only sets the DOS time?  Which only has a granularity of 2
seconds?  If so, how do you get back the same value you put in if the
current second is odd?  Or am I misunderstanding the test?


On Fri, Jul 6, 2018 at 4:46 PM, Xueming Shen <xueming.shen at oracle.com>
wrote:

> Hi
>
> Please help review the changeset for JDK-8206389
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8206389
> webrev: http://cr.openjdk.java.net/~sherman/8206389/webrev
>
> Cause: ZipOutputStream.writeCEN().writeCEN() incorrectly calculate the
> length
> of bytes needed for the  "unix timestamps" when the "last modified time" is
> NOT set. The info-zip spec specifies that
>
>           The central-header extra field contains the modification time
> only,
>           or no timestamp at all.  TSize is used to flag its presence or
>           absence.  But note:
>
> So in this case, when "creation time", "last access time" are set but the
> "last modified time" is not. only the "tag", "size" and "flag" should be
> output to
> the extra field, no real "mtime" timestamp, so the total size of the bytes
> needed
> is 5, not 9.
>
> Thanks,
> Sherman
>
>