Vacuon 0.3.1 — the size on disk was wrong

Disk space analyzer for Windows. Reads the NTFS MFT straight off the volume, shows the real content of what you are about to delete, and never claims a number it did not measure.

This release exists because 0.3.0 claimed one. It reported Size on disk 758 GiB for a 476 GiB volume, one line above the correct 377 GiB used of 476 GiB. Three separate defects fed that number, and nothing caught them because nothing was comparing the two totals the app printed a line apart.

Download

File	What it is	Size
Vacuon.exe	The app. Download this one.	62 MB
vacuon-cli.exe	Command line, for scripting	36 MB
Vacuon-0.3.1-win-x64.exe	Identical to Vacuon.exe, named for winget, which pins a hash	62 MB
vacuon-cli-0.3.1-win-x64.exe	Identical to vacuon-cli.exe, same reason	36 MB

Take Vacuon.exe. It keeps that name after downloading, and Windows shows a loose executable
by its file name — Vacuon-win-x64.exe in the Start menu reads like a build artefact.

Portable and self-contained: nothing to install, no .NET runtime needed, runs from a USB stick.

Vacuon-0.3.1-win-x64.exe      AF0E0D228A101F6B8E52433BDCF27778EDF35DF0F1D1D593E06313EE0E186FAC
vacuon-cli-0.3.1-win-x64.exe  8E86C997F5720638087AB384EE6AE773E8129345293457F39D462E764929CF80

Verify with Get-FileHash .\Vacuon.exe — the two names are the same bytes.

Windows will warn you — that is expected

The file is not code-signed, so Windows shows a blue "Windows protected your PC" screen the first time. Click More info → Run anyway.

If you would rather not trust an unsigned binary from a stranger, that is the correct instinct. Clone the repository and build it yourself: dotnet build -c Release.

Fixed: the size on disk was wrong

Three defects, all the same mistake — reading a field whose meaning is close to, but not the same as, what its name suggests.

The record header's link count is not the hardlink count. NTFS counts $FILE_NAME attributes at offset 0x12, and every name that does not fit 8.3 gets a second one in the DOS namespace. That marked 75% of a real volume as hardlinked — a downloaded .mp4, an installer .exe — and since hardlinked content is charged to the disk only once, it hid 217 GiB.

For a compressed or sparse attribute the on-disk size is at 0x40, not 0x28. Field 0x28 holds the run space as if nothing had been compressed or punched out.

$BadClus:$Bad is the size of the whole volume and occupies nothing. Together with $Extend\$UsnJrnl:$J, counting their logical size added 568 GiB to a 476 GiB disk.

The first attempt at fixing the third one read 0x40 only when the attribute carried the compressed or sparse flag — and $BadClus:$Bad carries no such flag on a real volume, so the total went from 758 GiB to 834 GiB. Which field to read is now decided by where the attribute header ends, and a separate rule refuses any single stream claiming more space than the volume has occupied.

New: the app checks its own arithmetic

Every scan now compares the space it attributed to files against what the volume reports as used, and says which way it came out. Measuring more than the volume holds is arithmetically impossible and always a bug, so it says so instead of printing the number as fact — and lists what is inflating the total. Measuring slightly less is the healthy case: directory indexes and metadata occupy clusters without being files.

Measured on a 476 GiB volume with 2.34 million files: 359 GiB attributed to files against 376 GiB reported as used, 95.4%.

Also fixed: the portable build was not portable

IncludeNativeLibrariesForSelfExtract had been lost from the project file, so WPF's five native libraries sat beside the executable instead of inside it. Running it from the build folder worked; copying the single file anywhere else killed the process before the window appeared, with no message. The 0.3.0 download was checked and is not affected.

There is now a crash handler that writes to %AppData%\Vacuon\crash.log, and a release check that runs the executable alone in an empty folder.

Verified in this release

• Raw MFT read, on a real volume, elevated: 2.34 million files in 11.5 seconds, about 203,000 files per second.
• USN journal delta: reopening applied 38 change records in 1.4 seconds instead of rescanning.
• Both binaries run standalone, copied out of the build tree into an empty folder.
• 187 tests.

Still not true

• There is no undo beyond the Recycle Bin. The reversible quarantine is milestone M4. Permanent deletion asks for an explicit acknowledgement precisely because of that.
• The Security tab is experimental and says so in the interface.

Requirements

Windows 10 21H2 or newer, x64. NTFS for the fast path; exFAT, FAT32, ReFS and network drives work through the slower traversal. Administrator only for the MFT read — the app opens the volume GENERIC_READ, never GENERIC_WRITE.