StatFS.blocks can't represent more than 2**32-1 blocks

[ValentinSteiner]

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

[juanarbol]

Does the BigInt option solves your problem?

Refs: https://nodejs.org/docs/latest/api/fs.html#filehandlestatoptions

[ValentinSteiner]

Unfortunately, it doesn't help. It's the same numeric value, but returned as BigInt.

[ValentinSteiner]

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

[juanarbol]

We can ping the Win Heroes @nodejs/platform-windows

[tniessen]

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.