Windows: Setting fs.futimes{Sync} subsecond (millisecond) precision?

[jprichardson]

According to nodejs/node-v0.x-archive#7000 (comment) this should be supported.

You can run the same snippet that TJ Fontaine posted in an aforementioned issue:

var fs = require('fs');

fs.writeFileSync('test.txt', 'abc');
console.log(fs.statSync('test.txt').mtime.getTime());
var a = new Date(1356171132123);
var b = new Date(1356171132321);
fs.utimesSync('test.txt', a, b);
console.log(fs.statSync('test.txt').mtime.getTime());
var fd = fs.openSync('test.txt', 'r+');
fs.futimesSync(fd, a, b); //<--- broken on Windows 7 / NTFS
console.log(fs.statSync('test.txt').mtime.getTime()); //<--- missing milliseconds Windows 7 / NTFS.

The output on Windows 7 / NTFS does not match the output he posted. i.e. it's missing milliseconds.

io.js version: v2.3.1.

[bnoordhuis]

I think you have a bug in your example. You are passing Date objects to fs.futimesSync() but what it really accepts are fractional numbers; the fractional part is the sub-second resolution. If you write it as fs.futimesSync(fd, a / 1e3, b / 1e3), it should work.

@nodejs/documentation The documentation can probably be improved, the above isn't mentioned; ditto for fs.utimes(). Perhaps we can support for Date objects as well.

[bnoordhuis]

Never mind, I see lib/fs.js already handles Date objects. In that case, can someone confirm the issue?

[targos]

Output of the script on Windows 10 (NTFS):

1435417400264
1356171132000
1356171132000

[rvagg]

NTFS and FAT only have 2s resolution for file times don't they?

[ivan]

NTFS has 100 nanosecond precision

[imyller]

At deps/uv/src/win/fs.c

INLINE static int fs__utime_handle(HANDLE handle, double atime, double mtime) {
  FILETIME filetime_a, filetime_m;

  TIME_T_TO_FILETIME((time_t) atime, &filetime_a);
  TIME_T_TO_FILETIME((time_t) mtime, &filetime_m);

  if (!SetFileTime(handle, NULL, &filetime_a, &filetime_m)) {
    return -1;
  }

  return 0;
}

time_t is UInt32 in Windows. This code effectively looses the fractional part (milliseconds) of double atime and mtime and keeps only the integer part (seconds).

I haven't tested this on Windows though. Just checked the docs.

[mathiask88]

@imyller time_t is a 64bit value on 64bit windows and since Visual C++ 2005 also on 32bit windows.

[imyller]

@mathiask88 Ok, __int64 it is. However, the bit depth does not really matter here.

Code is still casting a double to int and losing the milliseconds in fractional part.

[trevnorris]

If the floating part of the double contains sub second precision can't it be adjusted so the int64 actually represents time in ns?

[piscisaureus]

I think it would be possible to use 100ns precision using NtSetInformationFile.

[bnoordhuis]

@imyller is right though, isn't he? The cast to time_t loses the sub-second precision. Shouldn't this patch fix it?

diff --git a/deps/uv/src/win/fs.c b/deps/uv/src/win/fs.c
index 00d0197..7608737 100644
--- a/deps/uv/src/win/fs.c
+++ b/deps/uv/src/win/fs.c
@@ -1398,8 +1398,8 @@ static void fs__fchmod(uv_fs_t* req) {
 INLINE static int fs__utime_handle(HANDLE handle, double atime, double mtime) {
   FILETIME filetime_a, filetime_m;

-  TIME_T_TO_FILETIME((time_t) atime, &filetime_a);
-  TIME_T_TO_FILETIME((time_t) mtime, &filetime_m);
+  TIME_T_TO_FILETIME(atime, &filetime_a);
+  TIME_T_TO_FILETIME(mtime, &filetime_m);

   if (!SetFileTime(handle, NULL, &filetime_a, &filetime_m)) {
     return -1;

[jasnell]

@piscisaureus ... this would need to be fixed in libuv correct?

[bnoordhuis]

I've filed libuv/libuv#800.

[jasongin]

The fix was accepted: libuv/libuv@399e2c8. It should be available in libuv version 1.10.0.

[bnoordhuis]

Sorry, forgot to close out. It's been fixed in libuv/libuv#849, released in libuv v1.10.0 and node.js v7.1.0, and will eventually be available in a v4.x and v6.x LTS release.