https://bugs.openjdk.java.net/browse/JDK-8188869
really wanted to suggest to just unzip/jar & jar those jar files again,
as a workaround ...
-sherman
On 10/6/17, 7:02 AM, Claes Redestad wrote:
Hi,
it appears this is a difference where java.util.Date is carrying the
overflow(s), while the
java.time-based implementation is more strict. Same issue assumedly
exist for most
fields in the dos format (minutes can be 0-63, hours 0-31, days 0-31...).
The dosToJavaTime implementation was changed to use java.time mostly
as a cleanup
(https://bugs.openjdk.java.net/browse/JDK-8066644), but this
difference in strictness was
overlooked..
Most compelling option for now might be to revert to the code in 8:
public static long dosToJavaTime8(long dtime) {
@SuppressWarnings("deprecation") // Use of date constructor.
Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
(int)(((dtime >> 21) & 0x0f) - 1),
(int)((dtime >> 16) & 0x1f),
(int)((dtime >> 11) & 0x1f),
(int)((dtime >> 5) & 0x3f),
(int)((dtime << 1) & 0x3e));
return d.getTime();
}
/Claes
On 2017-10-06 14:24, Baesken, Matthias wrote:
Hello,
When iterating on the zip entries (and printing the time stamps) of
an old sqljdbc.jar the exception
"java.time.DateTimeException: Invalid value for SecondOfMinute (valid
values 0 - 59): 60"
occured (issue has been seen on Windows).
Looks like the dosToJavaTime function in ZipUtils.java of
jdk9/jdk10 is a bit more "sensitive"
about the input it gets, compared to jdk8.
In both implementations :
java.base/share/classes/java/util/zip/ZipUtils.java
jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
the computation of the "seconds" values is done by
public static long dosToJavaTime(long dtime) {
...
(int) ((dtime << 1) & 0x3e));
...
}
0x3e is binary 111110 or decimal 62, so larger values than the
supported maximum 59 can occur
(maybe only with old/problematic archives but still we had such an
example).
When looking a bit more closely into it, we found that the "second =
60" value was coming from a long value 930973758
that was passed to ZipUtils.dosToJavaTime as dtime argument.
(found this out by adding an enhanced chained exception to jdk9
showing the dtime value passed to dosToJavaTime).
Here is an example of the iteration on entries of such a "bad" zip
file :
C:\JVM\openjdk10\bin\java ZipIterate
Iterate von ZipFile:
--------------------------------------
name of
ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class
Exception in thread "main" java.time.DateTimeException: Invalid value
for SecondOfMinute (valid values 0 - 59): 60
at
java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
at
java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.java:714)
at java.base/java.time.LocalTime.of(LocalTime.java:322)
at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337)
at
java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101)
at
java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114)
at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
at ZipIterate.main(ZipIterate.java:37)
A similar problem (dealing with days/months not seconds out of
supported range) is described here :
https://bugs.openjdk.java.net/browse/JDK-8184940
"JDK 9 rejects zip files where the modified day or month is 0"
Compared to jdk8, this is a regression so I think it would be good
to have a better handling of problematic out of range seconds-values.
Do you think it would be sufficient to adjust the out of range
seconds to the supported max-value 59 ?
Or is something more sophisticated prefered ?
I found the enhanced chained exception showing the dtime long values
helpful too, should I submit it ?
Best regards,
Matthias
