nodejs
StatFS.blocks can't represent more than 2**32-1 blocks
Version
v25.2.1
Platform
Microsoft Windows NT 10.0.19045.0 x64
Subsystem
fs
What steps will reproduce the bug?
I'm using fs.statfs to obtain size information on SMB network drives. For an 8 TiB drive mounted via SMB, statfs reports 4 TiB.
const fs = require("node:fs/promises");
fs.statfs("\\\\myserver\\share").then(x => console.log(x.bsize*x.blocks / 1024**4));
The reason appears to be that StatFS.blocks is an unsigned 32 bit integer. With a bsize of 1024, this explains the 4 TiB.
It makes no difference whether I use a UNC path (\\server\share) or a mapped network drive with a drive letter. I believe it's a general limitation and not linked to SMB in particular. I couldn't test with a local disk, since I didn't have one with more than 2**32-1 blocks. The bigint option gives the same output, just as BigInt.
How often does it reproduce? Is there a required condition?
It reproduces reliably.
What is the expected behavior? Why is that the expected behavior?
I expect statfs to report accurate block counts, even above 2**32-1.
What do you see instead?
statfs block counts appear to be capped at 2**32-1.
> StatFs {
type: 0,
bsize: 1024,
blocks: 4294967295,
bfree: 39622500,
bavail: 39622500,
files: 0,
ffree: 0
}
Additional information
No response
Does the BigInt option solves your problem?
Refs: https://nodejs.org/docs/latest/api/fs.html#filehandlestatoptions
Unfortunately, it doesn't help. It's the same numeric value, but returned as BigInt.
Having dug into the source a little, I believe the 32 bit restriction comes from using GetDiskFreeSpace instead of GetDiskFreeSpaceEx in deps/uv/src/win/fs.c (in fs__statfs).
Disclaimer: not a Windows person
One complication here is that libuv returns filesystem information through objects of type uv_statfs_t:
typedef struct uv_statfs_s {
uint64_t f_type;
uint64_t f_bsize;
uint64_t f_blocks;
uint64_t f_bfree;
uint64_t f_bavail;
uint64_t f_files;
uint64_t f_ffree;
uint64_t f_spare[4];
} uv_statfs_t;
Not all fields of uv_statfs_t can be computed from the output of GetDiskFreeSpaceEx. We can probably first call GetDiskFreeSpace and then GetDiskFreeSpaceEx to calculate all field values, but that approach would be susceptible to the race condition arising from the process being interrupted between these calls.
I agree with the previous comment, GetDiskFreeSpace is required to get the f_bsize value. The implementation with 2 calls is straight forward, but there is a mentioned potential issue. Should we open a PR in libuv to continue the discussion there?
Given the mess that Windows is, I assume that these functions use something like DeviceIoControl with FSCTL_GET_NTFS_VOLUME_DATA internally, which however only works for NTFS volumes.
Perhaps someone from @nodejs/libuv would like to chime in.