fix(API): prefer frsize over bsize for disk-space calculation

TheLastCicada · TheLastCicada · commit 286fcbb90512 · 2026-05-12T14:01:41.000-07:00
Defensive fix from bugbot review of #1627. Node's fs.statfs() currently only exposes bsize (libuv's uv_statfs_t doesn't copy frsize from the underlying statfs(2) syscall), and on Linux+ext4 'blocks * bsize' matches 'df -B1' byte-exactly. But POSIX statvfs denominates blocks in frsize, not bsize, and on exotic filesystems (e.g. VirtioFS on Docker) the two can differ. Using 'stats.frsize ?? stats.bsize' is a zero-cost hedge that automatically picks up frsize if a future Node version or a polyfill exposes it, while keeping today's behavior unchanged on every mainstream environment.
diff --git a/src/utils/system-info.js b/src/utils/system-info.js
@@ -61,10 +61,19 @@ const getDiskInfo = async (targetPath) => {
     }
 
     const stats = await fs.promises.statfs(resolvedPath);
+    // Per POSIX statvfs(3) the `blocks`/`bavail` fields are denominated in
+    // `f_frsize` (fundamental block size), not `f_bsize` (optimal transfer
+    // block size). Node's libuv wrapper currently only exposes `bsize`, and
+    // on Linux+ext4 the two are equal so `blocks * bsize` matches `df -B1`
+    // byte-exactly. We still prefer `frsize` when present (some Node forks
+    // and future versions expose it) and fall back to `bsize` -- a zero-cost
+    // hedge against environments like Docker+VirtioFS where the two can
+    // differ.
+    const blockSize = stats.frsize ?? stats.bsize;
     return {
       path: resolvedPath,
-      totalBytes: stats.blocks * stats.bsize,
-      freeBytes: stats.bavail * stats.bsize,
+      totalBytes: stats.blocks * blockSize,
+      freeBytes: stats.bavail * blockSize,
     };
   } catch (error) {
     logger.debug(`[diagnostics]: failed to stat disk for ${targetPath}: ${error.message}`);
