Releases: joedsonalves/vacuon
Release list
Vacuon 0.5.0 — rules, look-alikes, a live monitor and preview
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.
Since 0.4.0: cleanup by rules, a live monitor with a screen, pictures and videos that look alike, and the preview panel.
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.5.0-win-x64.exe |
Identical to Vacuon.exe, named for winget, which pins a hash |
62 MB |
vacuon-cli-0.5.0-win-x64.exe |
Identical to vacuon-cli.exe, same reason |
36 MB |
Portable and self-contained: nothing to install, no .NET runtime needed, runs from a USB stick.
Vacuon-0.5.0-win-x64.exe 1A17D039E055571CF058FA1F894E3E4630134A9057E36FED0EC690B557031AE8
vacuon-cli-0.5.0-win-x64.exe A59A7B9684072029F1E31B984E1B59C79B4A19D30D1CBFF0A7BF5CC22EB89075
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, then 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.
New: cleanup by rules, which calls Microsoft's tools instead of deleting inside Windows
A rule catalogue finds junk by pattern and removes it — into the quarantine by default, so it is still reversible.
- Nothing under
%WINDIR%is deleted by hand. The protected-path list refuses everything below the Windows folder and has no override, so the rules that need to work in there call DISM, powercfg and vssadmin instead. That is better for a second reason, not just the first: deleting WinSxS by hand is how people end up unable to install the next update. There is a test that sweeps the whole catalogue looking for any path inside Windows. - Space freed by a tool is measured, never taken from what the tool says. DISM prints no total, vssadmin prints one that counts differently, and a catalogue's "typical gain" is a number from somebody else's machine. Free space is read before and after. If it went down in between, the result says there is no honest number rather than inventing one.
- Dry-run is structural, not a flag.
Executetakes a plan, not a profile, so a file that appeared between planning and execution is not included. There is a test that creates one in the middle. - A bad
rules.jsonno longer fails in silence. One wrong backslash makes the whole file unreadable, and the only symptom used to be that editing the file changed nothing, forever. Now the app names the file, the line and the character.
Measured on a real machine, dry-run: quick found 2,523 files and 1.2 GiB across 4 rules; deep added 11.1 GiB of npm cache and 3.0 GiB of NuGet.
New: a live monitor that shows what is filling the disk right now
vacuon watch C: reads the USN journal at intervals and shows, per folder, what is being created, deleted and written as it happens. There is a screen for it, a tray icon, and a low-space warning.
- It cannot tell you which process is responsible, and it says so on every run. A USN record carries the file, the folder, the reason and the attributes — it has no process id, because the journal is a filesystem log, not an audit trail. Naming a culprit would mean guessing from the path, and "this folder belongs to Chrome, so it was Chrome" is a plausible invention. Real attribution needs the ETW I/O provider, which is a different piece of work.
- Bytes come from the file's current size, because the journal says that something changed, never how much. A file created and deleted inside the same interval measures zero, and that is correct.
- A journal that dropped records is reported as a gap, not as a quiet interval.
- The trend refuses to guess. It projects "full in about N days" only when it has enough history to mean it.
Scheduled cleanups run through the Windows Task Scheduler and only ever move things to the quarantine. The space guard checks a threshold and deletes nothing.
New: pictures and videos that look alike
A 64-bit dHash over the pixels the thumbnail provider already returns — no image library is linked, so it reads whatever Windows can open. Icons are never hashed, or every .docx would become "the same picture".
Running it on a real disk produced one group of 110 different images announced as the same, and fixing that took three changes, not one:
- A near-uniform image gets no fingerprint. If every cell looks alike, every cell hashes alike. A fingerprint built on nothing should not exist.
- The group is re-checked against the keeper, not against the seed it grew from.
- The aspect ratio has to match within 2%. This is what actually resolved it: 49 different poker felts collapsed into 7 legitimate copies of the same
bgr.jpgin language folders. Two versions of one photo have the same shape; assorted felts do not.
Two things were tried, measured and undone: a 256-bit fingerprint (a finer grid picks up detail JPEG moves — three versions of one photo went from 0 bits apart to 27 and 34), and simply lowering the threshold (24 different playing cards at 70 px had a minimum distance of zero, and no threshold separates populations that overlap). What removed them was raising the size floor to 256 KiB — the false positives were never photographs, they were cards, sprites, wordmarks and interface decoration.
The limit is written down rather than hidden: a dHash groups by coarse resemblance, so two pictures of similar composition and identical shape can still land together. The mitigation is the screen — thumbnails side by side, the distance in bits, and nothing is removed unless you tick it.
Videos are compared by sampling frames, with no dependency added. Fingerprints are now cached between runs.
Also here: folders left behind by uninstalled programs, folders NTFS would compress well, and what changed between two scans.
New: the preview panel
- Media details without a media library. Duration, resolution, frame rate, codec and bitrate come from the Windows Property System — the same handlers as the Explorer Details tab.
vacuon media <file>prints the same thing. - Zoom and pan, because a preview scaled to fit cannot answer "which of these two copies is sharper", which is exactly the question being asked before deleting one.
- Syntax colouring for text and code, and a hex view for binary.
.logand.csvare deliberately not coloured: there is no syntax there to reveal, and colouring words in a log invents structure that does not exist. - Gallery mode and side-by-side comparison. Rows answer "how much space"; a grid answers "which one".
- The Windows context menu opens inside Vacuon's menu, not instead of it — the app's own menu carries the quarantine and the delete that respects the protected paths, and replacing it would take away the actions this program exists to offer.
- EXIF camera, date and location. The coordinate is printed to six decimals and stops there, which is about a tenth of a metre and finer than any consumer receiver.
What is deliberately still out
- The embedded video player. Measured before deciding: LibVLCSharp ships 101.8 MB of native libraries in 525 files, of which 325 are plugins that VLC looks for on the filesystem at runtime. In a single-file build they are not on disk. Making it work would mean extracting 325 plugins to
%LocalAppData%on first run, and then "portable, copying one file is enough" stops being true. The binary would go from 62 MB to about 160. - Audio fingerprinting for near-duplicate audio.
- Code signing, so the SmartScreen warning above stays.
Full changelog
Vacuon 0.4.0 — a quarantine, duplicate files, and the treemap
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.
Three milestones since 0.3.2: a reversible quarantine, an exact duplicate finder, and the treemap.
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.4.0-win-x64.exe |
Identical to Vacuon.exe, named for winget, which pins a hash |
62 MB |
vacuon-cli-0.4.0-win-x64.exe |
Identical to vacuon-cli.exe, same reason |
36 MB |
Portable and self-contained: nothing to install, no .NET runtime needed, runs from a USB stick.
Vacuon-0.4.0-win-x64.exe 6E5FD4BED729BED8C459D8746ECC1FD0E132D5E083CF655C169D408D1B4AA486
vacuon-cli-0.4.0-win-x64.exe 5D01D66597B0756D9A94DCC8811381FC11EFAF09979AB65E665C093665D50954
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.
New: the quarantine, so deleting is no longer the only way out
Vacuon can now set files aside instead of deleting them. Quarantine moves them into a folder on the same volume, records where each one came from, and puts them back on demand.
- It is a rename, so it does not depend on size. Measured on a 2 GiB file: writing it took 22 s, quarantining it 155 ms, restoring it 2.9 ms, with the SHA-256 identical on both sides. The 22 s is the number to compare against — that is what touching the bytes costs, and the quarantine does not touch them.
- It frees nothing, and the app says so. The report says held, never freed, and there is no "freed" figure to reach for by accident. Purging a batch is what returns the space, and that is the only step in the quarantine with no undo.
- Restore never overwrites. If something has taken the original path back, the item stays where it is and says so. An undo that destroys a file you never asked to lose is worse than no undo.
- The manifest is written before anything moves. The failure that loses data is not a half-finished batch — it is a file sitting in the store under a numbered name with nothing recording where it came from. A crash at any point leaves a manifest describing the whole intent.
- The quarantine folder is on the protected list. It holds exactly what you already decided to remove, which makes it the most attractive folder on the disk to a cleanup tool, including this one.
vacuon quarantine list | restore <batch> | purge <batch> does the same from the command line. Purge refuses to run without --yes.
New: duplicate files, in four stages
Groups by size straight from the index, then hashes the first 8 KiB, then the last 8 KiB, then the whole file.
The verdict is always the full-file hash. The sampled stages exist to avoid reading terabytes, never to decide anything — two renders out of the same encoder share a size, a header and a trailer, and calling them identical on that evidence is exactly the false positive a duplicate finder must not produce.
- A hardlinked copy is identical and frees nothing. NTFS charges the content once and releases it only when the last name goes, so those copies are excluded from the recoverable figure, counted separately, and preferred as the one to keep — keeping them is free.
- "Delete every copy" is not something the screen can express. The copy that stays has no checkbox at all, not a disabled one.
- The cost is quoted before anything is read. Grouping by size is free, so the tab opens by telling you what the rest would cost — on the machine this was built on, 793,590 candidates in 76,125 size groups, up to 105 GiB to read. It says that is the worst case, and that the real fraction is not knowable in advance. There is a progress count and a stop button.
Ticked copies go to the quarantine, not to deletion.
A measurement worth repeating: grouping by size filters far less than it looks like it should. On a real 2.49 M file volume, 1.63 M files fall under the 4 KiB minimum, and of the 857 k left, 769 k still share a size with something else. Sizes cluster, because the things that fill a disk come out of the same encoders, compilers and installers.
vacuon duplicates <drive|folder>, with --min-size, --keep=oldest|newest|shallow and --verify.
New: the treemap
Every box is sized by what it takes on disk, so the biggest thing on screen is the biggest thing on the volume. Click a folder to go in.
- Squarified, not the naive slice-and-dice, which gives every item the full height of the canvas and turns a small folder into a one-pixel line nobody can click. On the same data the worst aspect ratio is under 12 instead of over 200.
- Area is exactly proportional to size, and boxes never overlap — both are covered by tests, because a treemap that is slightly wrong looks exactly like one that is right.
- Folders are coloured by whatever fills them. The first version came out almost entirely grey: the top level of a volume is nearly all folders, and a folder has no extension. Now a branch that is mostly video looks like video. Virtual disks got their own colour for a concrete reason — nine
.vhdxfiles hold 106 GiB on the development machine, and grey was hiding the biggest thing on the disk. - One
DrawingVisualrather than an element per box: 100,000 rectangles lay out in under half a second, and a real volume's top level draws in 1–3 ms.
Also in this release
- The version now reads the same in the assembly metadata and in the app, with a test comparing them. They had drifted — the window footer said 0.3.2 while the file properties said 0.3.1.0.
- The footer stops describing the app as it was three milestones ago.
winget install vacuonis documented, and the README stops implying the package lands in the Start menu —InstallerType: portableputsvacuonon yourPATHand creates no Start entry, for every portable package.- The
duplicate-findertag was removed from the winget manifest in 0.3.2: at the time the app did not find duplicates. It does now.
Verified in this release
- 318 tests, run on every commit.
- Both binaries run standalone, copied on their own into an empty folder outside the build tree.
- The quarantine, the duplicate finder and the treemap were each exercised against a real volume, not only against fixtures.
Vacuon 0.3.2 — moving files, and the first switches that turn things off
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.
Vacuon is now on winget. winget install vacuon works — the package was accepted into microsoft/winget-pkgs on 21 August.
This release adds the first actions that change something other than your files: a Move to… that overwrites nothing, and an Optimize section that can turn Windows features off. Everything it turns off, it can turn back on.
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.2-win-x64.exe |
Identical to Vacuon.exe, named for winget, which pins a hash |
62 MB |
vacuon-cli-0.3.2-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.2-win-x64.exe 674DE1371A6F0B9C4A37EA56BAB9CC7331E21B01410297FCDF0765B51983E0BB
vacuon-cli-0.3.2-win-x64.exe C213263CBF52A358FDA87BD8796EEDC9D6963FF72FE8F1CFD1E993D9B6BD29CB
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.
New: moving files
Sorting a folder by hand is not deleting. You open a file, decide, and it either stays or goes somewhere else — so Move to… works on the ticked basket, which survives opening files, changing folder, sorting and searching. Space ticks whatever is highlighted, which makes a pass through a folder: open, look, Esc, Space.
- Nothing is ever overwritten. A name the destination already uses goes in as
render (2).mp4, and the confirmation lists which ones will be renamed before anything moves. That includes two files with the same name arriving from two different folders in one batch — each one sees an empty destination, so only the batch itself can catch it. - A move on the same volume frees no space, and the dialog says so instead of adding the size to a total as if it had. It rewrites a directory entry; it is instant, and the disk gives nothing back. Moving to another volume is a copy plus a delete, which does free space here, and the figure comes from the entries that left.
- Destinations are judged differently from deletion targets.
Videosmust not be deleted and is a perfectly ordinary place to move a video into. What is refused is writing into what Windows and installed programs own. - Creating the destination folder in the picker is the normal way to start sorting, so Vacuon adopts a folder younger than the scan into the index at its real MFT record number, read from the file system. When it cannot place it, the app says the scan is now behind the disk and to press
F5, instead of showing files where they no longer are.
New: the Optimize section
Three panels, and they share a door on purpose: they are the only parts of Vacuon that write to your machine. Everything else reads.
AI components. Shows the state of each Microsoft AI component, how much memory it is using right now, and turns off the ones Microsoft documents a control for. Cost is measured, never estimated — zero is an answer, and the panel says "nothing running now" instead of implying a saving. Every write is read back, because "I wrote it" and "it is there" are different claims and only the second is shown. Undo restores from the journal rather than writing the value "on": deleting a value Vacuon created is not the same as setting it to zero. Nothing from third parties is in the catalog, and there is a test that keeps it that way.
Startup. Shows what Windows launches when you sign in and disables entries without deleting them, using the same control Task Manager uses. Entries pointing at a file that no longer exists are flagged.
Memory. This one is deliberately not a RAM cleaner, and the panel explains why. EmptyWorkingSet pushes pages to standby or the pagefile and they come back from disk the moment a program touches them, so on a machine that is not short of memory it usually makes things slower.
- It sorts by private memory, not working set. Working set counts a shared page once per process, so summing it across Opera's 54 children reports more memory than the machine has. Both figures are on the row, labelled.
- The trim button exists, and its result is reported as moved, never freed — and
MovedBytescan be negative when Windows pulls pages back, which the interface shows rather than hides. - Memory Compression gets its own line instead of sitting in the consumer list: it is the largest working set on the machine with almost no private memory, and the first target of any cleaner. Attacking it trades fast RAM for disk reads.
- Closing a program from the list does free memory, so there the word is honest — and it reports two numbers, what the process held and how much available memory actually rose, because they rarely match.
Measured on the development machine: 31.8 GiB total, 20.0 in use, Opera holding 10.1 GiB private; the trim moved 2.0 GiB, and the sentence beside it explains where they went.
Deleting and selecting
- Fixed a visual bug: what you deleted stayed in the list and in the tree, and came back on the next search.
- Selection survives changing folder, sorting and searching, with a tick column and select all / invert / clear.
- Search gains a checkbox for only inside the selected folder, and one for include folders — search now finds a folder by name.
- Columns sort by name, size, date and path.
- The Recycle Bin stops saying "freed" for what was only moved there, and shows how much is waiting.
- A selected folder now adds up everything inside it instead of reporting zero.
- Fixed
1 items deletedand1 foldersin the singular.
Command line and housekeeping
vacuon aiandvacuon startup, both read-only.winget install vacuonis the documented route.- The README stops implying winget hands you the CLI. It hands you the window: the manifest ships the GUI with
Commands: [vacuon]. - It also stops implying the app lands in the Start menu. It does not:
InstallerType: portablestores the executable and putsvacuonon yourPATH, and portable packages get no Start menu entry — that is winget's behaviour for every portable package, not a failed install. The README now says so, and how to open it. - The version is now the same number in the assembly and in the code, with a test that compares them.
AppInforead 0.3.2 while the file properties Windows shows read 0.3.1.0, and the test that was supposed to guard this only checked the format — so it passed while the two disagreed.
Verified in this release
- 263 tests, run on every commit.
- Both binaries run standalone, copied out of the build tree into an empty folder — the check that caught the 0.3.1 near-miss where WPF's native libraries sat loose beside the executable.
- The published binary is the tested binary: the SHA256 above is the file that was installed through winget and run on the development machine.
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.
Vacuon 0.3.0
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.
Download
| File | What it is | Size |
|---|---|---|
Vacuon-0.3.0-win-x64.exe |
The app. Download this one. | 62 MB |
vacuon-cli-0.3.0-win-x64.exe |
Command line, for scripting | 36 MB |
Both are portable and self-contained: nothing to install, no .NET runtime needed, runs from a USB stick. Download, double-click, done.
Windows will warn you — that is expected
The file is not code-signed (a certificate costs money and this is a hobby project), so Windows shows a blue "Windows protected your PC" screen the first time.
To run it anyway: click More info → Run anyway.
If you would rather not trust an unsigned binary from a stranger on the internet — that is the correct instinct. Clone the repository and build it yourself:
git clone https://github.com/joedsonalves/vacuon.git
cd vacuon
dotnet build -c Release
SHA256, so you can check that what you downloaded is what was published:
Vacuon-0.3.0-win-x64.exe 69297202CFB1DD1AEEFAE06FC5DDF5490622753EDA14DDB568511C47C5B98C9E
vacuon-cli-0.3.0-win-x64.exe F5758D6D9DCFF11A8435733A89E880A7D133781038352B3AA9D787C6132F578C
Verify with Get-FileHash .\Vacuon-0.3.0-win-x64.exe.
Run it as Administrator for the fast path
Vacuon opens without asking for anything. Click Scan and it works — through the Windows API, which took 34 seconds for 2.6 million files on the machine it was developed on.
Reading the NTFS MFT directly is the fast path (3–8 seconds for a million files), and Windows only allows that to an elevated process. Two ways to get it:
- click Restart elevated in the bottom-left corner, or
- turn on Always run as administrator in Settings.
Either way Windows shows the UAC prompt. There is no way around that, and the app says so instead of pretending otherwise. Vacuon opens the volume read-only — GENERIC_READ, never GENERIC_WRITE.
What it does
- Dashboard — where the space went: biggest files, biggest folders, breakdown by type, size and age.
- Explorer — folder tree sorted by size (not by name), instant search, filters by size, age and extension.
- Thumbnails in six sizes — images and videos show their real content, so you can tell which of five 9 GB renders is the final one without opening any of them.
- Delete —
Delto the Recycle Bin,Shift+Delpermanently. Multi-selection in both panes. A protection list that nothing overrides refuses the volume root, Windows, System32, Program Files, well-known profile folders and kernel-owned files. - Security — 44 registry points where malware commonly takes root, read-only, with the reason for every finding in plain sight. Marked experimental, because it is.
Interface in English (default) or Portuguese, switchable in Settings without restarting. Light and dark themes.
Honest about what is not verified
- The MFT read has not been exercised end to end. It compiles, it is covered by 170 tests against synthetic MFT records, and its failure path is verified — but nobody has yet watched it index a real volume, because that needs elevation and the development session did not have it.
- The USN journal delta is in the same position. The snapshot round-trip and every refusal path are tested; the delta itself is not.
- 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.
Requirements
Windows 10 21H2 or newer, x64. NTFS for the fast path; exFAT, FAT32, ReFS and network drives work through the slower traversal.