-
Enhancement
-
Resolution: Fixed
-
P4
-
None
-
b08
-
x86_64
-
linux
A DESCRIPTION OF THE REQUEST :
A comment in
sun/nio/fs/UnixFileAttributes#toFileTime(long,long)
( http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/nio/fs/UnixFileAttributes.java#UnixFileAttributes.toFileTime%28long%2Clong%29 ) states:
// truncate to microseconds to avoid overflow with timestamps
// way out into the future. We can re-visit this if FileTime
// is updated to define a from(secs,nsecs) method.
It seems like it's possible to re-visit this decision now, since FileTime provides a "from(Instant)" method since
1.8, which would make it possible to up the resolution to nanoseconds.
I sent a mail to nio-discuss regarding this, and Alan Bateman asked me to report this bug: http://mail.openjdk.java.net/pipermail/nio-discuss/2017-June/000736.html
JUSTIFICATION :
In my case I would like the full resolution of the underlying fs in order to be able to produce equal timestamps to system utilities such as "diff".
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
That FileTime timestamps aren't truncated to nearest microseconds, but have the full nanosecond resolution of the underlying file system.
ACTUAL -
I see truncation to nearest microsecond.
---------- BEGIN SOURCE ----------
public static void main(String[] args) throws IOException, InterruptedException {
Path file = Files.createTempFile("test", "test");
String fsTimestamp = "2017-01-01 01:01:01.123456789";
String[] cmd = {"touch", "-m", "-d", fsTimestamp, file.toString()};
Process process = Runtime.getRuntime().exec(
cmd);
int exitCode = process.waitFor();
if (exitCode != 0) {
throw new RuntimeException("Command '" + Arrays.toString(cmd) + "' got exit code " + exitCode);
}
FileTime time = Files.getLastModifiedTime(file);
String javaTimestamp = time.toInstant().atZone(ZoneOffset.UTC).format(DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss.SSSSSSSSS"));
if (!javaTimestamp.equals(fsTimestamp)) {
throw new IllegalStateException("Expected fs timestamp to be '" + fsTimestamp + "', but was '" + javaTimestamp + "'");
}
}
// Output:
// Exception in thread "main" java.lang.IllegalStateException: Expected fs timestamp to be '2017-01-01 01:01:01.123456789', but was '2017-01-01 00:01:01.123456000'
---------- END SOURCE ----------
A comment in
sun/nio/fs/UnixFileAttributes#toFileTime(long,long)
( http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/sun/nio/fs/UnixFileAttributes.java#UnixFileAttributes.toFileTime%28long%2Clong%29 ) states:
// truncate to microseconds to avoid overflow with timestamps
// way out into the future. We can re-visit this if FileTime
// is updated to define a from(secs,nsecs) method.
It seems like it's possible to re-visit this decision now, since FileTime provides a "from(Instant)" method since
1.8, which would make it possible to up the resolution to nanoseconds.
I sent a mail to nio-discuss regarding this, and Alan Bateman asked me to report this bug: http://mail.openjdk.java.net/pipermail/nio-discuss/2017-June/000736.html
JUSTIFICATION :
In my case I would like the full resolution of the underlying fs in order to be able to produce equal timestamps to system utilities such as "diff".
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
That FileTime timestamps aren't truncated to nearest microseconds, but have the full nanosecond resolution of the underlying file system.
ACTUAL -
I see truncation to nearest microsecond.
---------- BEGIN SOURCE ----------
public static void main(String[] args) throws IOException, InterruptedException {
Path file = Files.createTempFile("test", "test");
String fsTimestamp = "2017-01-01 01:01:01.123456789";
String[] cmd = {"touch", "-m", "-d", fsTimestamp, file.toString()};
Process process = Runtime.getRuntime().exec(
cmd);
int exitCode = process.waitFor();
if (exitCode != 0) {
throw new RuntimeException("Command '" + Arrays.toString(cmd) + "' got exit code " + exitCode);
}
FileTime time = Files.getLastModifiedTime(file);
String javaTimestamp = time.toInstant().atZone(ZoneOffset.UTC).format(DateTimeFormatter.ofPattern("uuuu-MM-dd HH:mm:ss.SSSSSSSSS"));
if (!javaTimestamp.equals(fsTimestamp)) {
throw new IllegalStateException("Expected fs timestamp to be '" + fsTimestamp + "', but was '" + javaTimestamp + "'");
}
}
// Output:
// Exception in thread "main" java.lang.IllegalStateException: Expected fs timestamp to be '2017-01-01 01:01:01.123456789', but was '2017-01-01 00:01:01.123456000'
---------- END SOURCE ----------
- relates to
-
JDK-8229280 (fs) test/jdk/java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java failing on older kernels
-
- Resolved
-
-
JDK-8231174 (fs) FileTime should have 100ns resolution (win)
-
- Resolved
-
- links to