Missing accuracy while getting ino (获取ino 精度丢失)

[spiritwindy]

• Version:1-9.0
• Platform:win
• Subsystem:
  node fs.stat 获取文件 ino 精度丢失

[XadillaX]

Translation

Title: Missing accuracy while getting ino

Content:

• Version: 1-9.0
• Platform: win
• Subsystem:

Accuracy lost while getting ino via fs.stat.

[XadillaX]

I think it because the ino in libuv is a unsigned int64:

typedef struct {
    uint64_t st_dev;
    uint64_t st_mode;
    uint64_t st_nlink;
    uint64_t st_uid;
    uint64_t st_gid;
    uint64_t st_rdev;
    uint64_t st_ino;
    uint64_t st_size;
    uint64_t st_blksize;
    uint64_t st_blocks;
    uint64_t st_flags;
    uint64_t st_gen;
    uv_timespec_t st_atim;
    uv_timespec_t st_mtim;
    uv_timespec_t st_ctim;
    uv_timespec_t st_birthtim;
} uv_stat_t;

And when filling to Node.js, it will be changed to double:

void FillStatsArray(double* fields, const uv_stat_t* s) {
  fields[0] = s->st_dev;
  ...

  fields[7] = s->st_ino;
  fields[8] = s->st_size;

  ...
}

Refs

• http://docs.libuv.org/en/v1.x/fs.html#c.uv_stat_t
• https://github.com/nodejs/node/blob/v9.0.0/src/node_file.cc#L435-L467

[XadillaX]

How about add some function like fs.safeStat and make these value be a buffer or a number string?

[mscdex]

There is no real solution for this until JS gets BigInt support, which is currently in stage 3. We've had this discussion before, and IMHO we should still wait for BigInt.

[XadillaX]

@mscdex but how could @spitWind get it correctly now?

[XadillaX]

Or maybe we could provide the raw uv_stat_t buffer to fs.Stats to let them parse by themselves?

[gireeshpunathil]

Please clarify: is it just accuracy? As inode numbers are unique identifiers into the disk blocks, I believe any change in the number leads to incorrect and unusable value as opposed to less accurate one?

[XadillaX]

@gireeshpunathil That's it. That's why I propose a safer one or a raw one.

[gireeshpunathil]

@XadillaX - thanks! I Agree that it is a bug that needs to be fixed. If there is no data type to support it, we should not record it in the first place, as not having an info is better than recording wrong info.

[mscdex]

as not having an info is better than recording wrong info.

I don't really agree with that. It's hard to say how often this is actually a problem in production. This is only the second time anyone has ever brought it up that I've ever seen.

[XadillaX]

@spitWind Could you please tell us that the situation you have to get this value in production?

[gireeshpunathil]

@mscdex - the problem is that it may not manifest as a problem. Wrong but valid inodes can corrupt files inadvertently, and may not be noticed easily.

[bnoordhuis]

Closing, duplicate of #12115.

[spiritwindy]

你们可以设置成_int64的，然后获取到原生的buffer比较 buffer就可以确认，，或者字符串

[spiritwindy]

貌似得解决下～～

[spiritwindy]

怎么超全局(针对机器)hook node里面的module?比如 fs模块

[spiritwindy]

两个原因，js 精度。。另外一个是double64..

[XadillaX]

@spitWind: You may set it to __int64, Buffer or String.

@spitWind: It seems that this really is a bug and should be resolved.

[spiritwindy]

thank you @XadillaX