Repository navigation
fs.stat and fs.statSync may not return identical struct #12419
Description
- Version: 7.9.0
- Platform: Windows 10 (64 bit)
- Subsystem: fs
Simple code example is here: https://github.com/proxy/gist.github.com/DoumanAsh/a70b49b3e05aa4c4273dd6917cce13e0
Occasionally found that Stats.dev differs for sync and async versions.
I'm not really sure how it is possible considering that both should use the same OS API...
All other fields are identical
Sync stats output:
Stats {
dev: 3163614271,
mode: 16822,
nlink: 1,
uid: 0,
gid: 0,
rdev: 0,
blksize: undefined,
ino: 5066549581028165,
size: 0,
blocks: undefined,
atime: 2017-04-15T06:12:53.786Z,
mtime: 2017-04-15T06:12:53.786Z,
ctime: 2017-04-15T06:12:53.786Z,
birthtime: 2017-04-15T06:03:09.505Z }
Async stat output
Stats {
dev: -1131353025,
mode: 16822,
nlink: 1,
uid: 0,
gid: 0,
rdev: 0,
blksize: undefined,
ino: 5066549581028165,
size: 0,
blocks: undefined,
atime: 2017-04-15T06:12:53.786Z,
mtime: 2017-04-15T06:12:53.786Z,
ctime: 2017-04-15T06:12:53.786Z,
birthtime: 2017-04-15T06:03:09.505Z }
Activity
bnoordhuis commentedon Apr 15, 2017
.devis derived from VolumeSerialNumber, which is a 32 bits unsigned integer. It should fit comfortably in a 64 bits double and it should not (and should not be possible for it to) be less than zero.Interestingly,
3163614271and-1131353025are the same 32 bits bit pattern so this is likely some integer->double conversion bug but it's not immediately obvious to me where it happens. Both the code in libuv and src/node_file.cc look okay at first glance.DoumanAsh commentedon Apr 15, 2017
@bnoordhuis i didn't go as far as looking into libuv code, but at least i didn't spot anything in node code itself...
Sadly i don't have possibility to test it on any unix like system, so cannot say if it is windows specific bug or not.
refack commentedon Apr 15, 2017
Looking into it with
windowsglasses onmscdex commentedon Apr 15, 2017
@DoumanAsh Did you try with previous v7.x versions and/or other major versions?
DoumanAsh commentedon Apr 15, 2017
@mscdex I remember having this issue in past on some older 7.x version, but cannot say for sure right now.
UPD:
Before v7.7 i get negative integer in both cases
After v7.7 we have current behavior
seishun commentedon Apr 15, 2017
How did you create the file?
DoumanAsh commentedon Apr 15, 2017
Just
gvim <file>mscdex commentedon Apr 15, 2017
The issue is that some optimizations were made to the
fs.*statSync()methods awhile back that bring uniformity to how the stat values are represented (they're all doubles now, whereas previously it was all a mixture of 3 different types -- double, signed int, unsigned int). The changes to thefs.*stat()methods were included in a follow-up PR which was marked as semver-major by me because of other unrelated changes in that PR.So either #11665 has to be backported, or only the
fs.*stat()-related changes have to be backported. Also just to note, the positive values should actually be more correct more often than not now (due to larger unsigned value range in double vs signed integer).Trott commentedon Aug 6, 2017
This is fixed in 8.x and the only affected currently-supported release line is 6.x? [EDIT: To be clear, that's a question, not a statement.]
mscdex commentedon Aug 6, 2017
@Trott yes, but I'm leaning towards just counting both PRs as semver-major (currently one is and the other isn't), which would mean no backporting at all. As far as the changes themselves go, changing the values in v6.x would be viewed as semver-major anyway, in case someone is relying on the signed-ness of the value.
gireeshpunathil commentedon Apr 27, 2018
@mscdex - this looks like a close candidate with no pending actions, right?
gireeshpunathil commentedon May 20, 2018
inactive, closing. please re-open if it is still outstanding.