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@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