fix(nesdoctor): report storage properly, and stop being blind on Windows

A submission from a team machine with four drives and 22 TiB reported
`disk=8880`, and the field was not wrong so much as meaningless: it was the
free space on the single largest mount, with no capacity anywhere and no total.
A content store is sized against capacity.

Storage now reports four things, because they answer different questions and
one number could not:

  diskfree   total free across every real filesystem
  disksize   total capacity
  diskmax    the largest single filesystem, which is the real ceiling for any
             one store -- a dataset cannot be spread across drives
  disks      how many there are

The ambiguous `disk` key is gone rather than silently redefined, so old rows
stay readable as what they were. `Get-PSDrive` reports Free *and* Used and we
were reading only Free, hence no capacity on Windows at all.

Pseudo-filesystems are now excluded by *type* rather than by mount path. Path
filtering missed `/tmp` on a tmpfs, whose free space is RAM -- so 7 GiB of
memory was being added to a storage total, which is exactly the sort of number
a capacity plan gets built on.

## The real finding, which was not about disks

"We are working blind on Windows" is correct, and both Windows bugs this tool
has had prove it: a virtual display adapter reported as the GPU, and a URL
truncated at its first `&`. Both were in code that only runs on Windows, both
were found by a person reading the results channel, and neither could have been
found here -- the development machine is Linux and `xdg-open` never sees a
shell.

Two things about that, and the first is the one that generalises.

`OPENERS` is now a const with a test asserting the property that actually
matters: **never hand a URL to anything that will re-parse it.** No `cmd`, no
`sh`, no `powershell`, no `start` builtin, and no argument that looks like it
wants the URL interpolated into it. Unlike the bug, that is checkable on every
platform in a millisecond. Verified by reintroducing `cmd /C start "" <url>`
and confirming the test fails with the right message, then reverting.

And CI already runs a real Windows machine and a real macOS one -- we simply
were not looking at them. Each smoke-tested target now prints its full report
and JSON into a collapsed log group. Deliberately not `set -e`: this step is
for looking, and a probe that misbehaves on a runner must not fail a release.
It turns "working blind" into "looking at it once per release", which would
have shown the Parsec adapter problem the first time a Windows binary was ever
built.

Version to 0.2.2.
This commit is contained in:
Wanjohi
2026-09-02 16:10:05 +03:00
parent a84886861c
commit 786267f30a
6 changed files with 214 additions and 32 deletions

View File

@@ -104,6 +104,33 @@ jobs:
fi
test -s "$RUNNER_TEMP/nd.json"
# Eyes on the platforms the developer machine is not.
#
# Every Windows bug this tool has had was found by a person reading the
# results channel: a virtual display adapter reported as the GPU, and a
# URL truncated at its first `&`. Both were in code that only runs on
# Windows, and the development machine is Linux -- so nobody had ever
# seen what these probes return on the platform most of the audience
# uses.
#
# CI already runs a real Windows machine and a real macOS one. Printing
# the full report from each is nearly free and turns "we are working
# blind" into "we are looking at it once per release".
- name: Show what the probes actually return here
if: matrix.smoke
shell: bash
run: |
set -uo pipefail
BIN="target/${{ matrix.target }}/release/${{ matrix.bin }}"
echo "::group::${{ matrix.target }} — full report"
# Not `set -e`: this step is for looking, and a probe that fails on a
# runner must not fail the release.
"$BIN" --no-net --no-steam --json "$RUNNER_TEMP/probe.json" < /dev/null || true
echo "::endgroup::"
echo "::group::${{ matrix.target }} — JSON"
cat "$RUNNER_TEMP/probe.json" 2>/dev/null || echo "(no json written)"
echo "::endgroup::"
- name: Package
shell: bash
run: |