Suspect signed/unsigned bug in the fs module of Node 6 and up on Windows

[erikkemperman]

• Version: Node 6 and higher
• Platform: Windows
• Subsystem: fs

There seems to be a signed/unsigned bug in the fs module of Node 6 and higher on Windows.

Specifically, I see different values in fs.Stats.dev for the synchronous and asynchronous versions fs.stat() and fs.statSync() (for the same file, obviously).

This only happens on Windows (well, technically Appveyor, I am unable to try it locally because I don't have a Windows machine at hand) and only in Node 6 and up.

I've created a minimal repository demonstrating this bug, here.

The assertion that fails on Appveyor Node >= 6 but passes on Node < 6, is here:
https://github.com/erikkemperman/windows-stats-quirk/blob/master/test/quirk.js#L11

As you see in the logs, it got stat.dev == -726974396 from the async call, but it got stat.dev == 3567992900 from the sync call!

This happens to be what you get if you cast the former, in C, from int32_t to uint32_t, so I suspect something like that must be going wrong in Node/LibUV.

#include <stdint.h>
#include <stdio.h>
int main() {
  printf("%u\n", (uint32_t) -726974396); // 3567992900
}

The older Node versions, up to 5, are fine, and so are all of the versions on Travis.

Thanks for taking the time, hopefully this bug report will be somewhat helpful in improving an already pretty awesome platform!

[mscdex]

Probably need something like #12614 for v6.x since it could be that an incomplete backport was done to v6.x at some point.

[erikkemperman]

FYI it also happens with lstat and lstatSync, as well as fstat and fstatSync. Updated my repo to demonstrate this:

https://github.com/erikkemperman/windows-stats-quirk/blob/master/test/quirk.js#L23
https://github.com/erikkemperman/windows-stats-quirk/blob/master/test/quirk.js#L35

All of these fail on Appveyor but pass on Travis.

Also, I think it might be possible for something like this to happen for other fields than dev but those are probably just less likely to overflow like this.

[gireeshpunathil]

link #12419

[TimothyGu]

I believe this has been fixed by #16705.