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

Why this is a good first issue

The issue involves Windows-specific filesystem handling and libuv internals.

AI Summary

The issue reports that `fs.statfs` cannot accurately represent block counts above 2**32-1 on Windows, likely due to the use of `GetDiskFreeSpace` instead of `GetDiskFreeSpaceEx` in libuv. The fix would require changes to libuv's Windows implementation, which may involve coordination with the libuv maintainers and Windows platform experts.

Issue Description

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

GitHub Labels

windowslibuv