On 07/07/2018 00:46, Xueming Shen 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
OK, looks good!
I would add something to check() to make sure that e.g. atime == null iff
ze.getLastAccessTime() == null
The zip time stuff is surprisingly messy.
On Fri, Jul 6, 2018 at 8:50 PM, Xueming Shen
wrote:
> On 7/6/18, 5:43 PM, Martin Buchholz wrote:
>
> I would use different
On 7/6/18, 5:43 PM, Martin Buchholz wrote:
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.
webrev has been updated accordingly.
+// ze.setLastModifiedTime(now);
+
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
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
