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