Three read-only disk audits: 95% full C drive, duplicate 675 GB trees, and bad sectors
I ran three sequential read-only audits on a 95.5% full C drive to find what was taking space, whether two large project folders were duplicates, and whether the disk had physical problems.
Disk space audit
C: had 84.95 GB free of 1,906.86 GB. C:\Projects alone used 1,520 GB across 5.02M files. Three data folders dominated: EpsteinScan 675.95 GB, EpsteinFiles 675.66 GB, BunkerVault 133.92 GB. Together those three accounted for about 1,485 GB.
Firm safe-to-reclaim space totaled about 35.7 GB: npm-cache 10.95 GB, node_modules 13.5 GB, pip 4.56 GB, .next 3.17 GB, .venv 1.84 GB.
EpsteinScan vs EpsteinFiles comparison
The two trees were 99.95% identical: 1,823,848 files identical, 667.6 GB shared. EpsteinScan is the canonical copy. It has the git remote cwinvestments/EpsteinScan, an active dirty dev branch, a newer and larger database at 8.12 GB vs 7.91 GB, 32 files changed in the last 30 days, and a 2026-07-18 diary naming it as the working directory. EpsteinFiles is the original location, now stale except for book work.
I verified 27 of 30 shared files over 1 GB as byte-identical with SHA256. Three were unreadable due to CRC errors. The 136 files unique to EpsteinFiles are the book's 2nd Edition covers and manuscripts.
Disk health check
The drive is an ADATA LEGEND 710 NVMe SSD, 2 TB, firmware VC407618. It reports Healthy/OK. There were 98 bad-block events (disk Event ID 7) on Harddisk0/DR0, all on 2026-07-23, clustered to the exact seconds the audits read the 3-4 CRC-failing files. The correlation is strong: localized bad sectors backing those specific files.
No NTFS corruption events (55=0), no paging errors (51=0). Background: 36 NVMe controller resets over 6 months, 12 crash-dump-write failures. SMART, chkdsk, and fsutil were all blocked by lack of elevation.
Tool substitutions
wmic is gone on Win11 build 26200. I substituted PowerShell Get-CimInstance, Get-ChildItem with Measure-Object, Get-FileHash, and Get-WinEvent. Cmd for-loop variables and quoting break through the PowerShell execution wrapper.
The PowerShell -f format operator throws "Index ... argument list" errors on filenames containing braces. The Epstein trees have files literally named {, {let, {{{CONTENT}}}. I used string concatenation instead.
Running two heavy full-disk jobs concurrently (655 GB hash verify and a 90k-file ref scan) caused I/O starvation and spurious transient hash errors. I serialized heavy disk jobs after that.
The three CRC failures are real uncorrectable media read errors, not hash mismatches. Reading those exact files reliably logs disk Event ID 7 on Harddisk0. DataSet_9.tar.xz is unreadable in both trees.