I build yyzTools — a free, local-first Windows toolkit that folds 40+ tools (command palette, file search, clipboard history, OCR, batch processing) into one installer. The 1.0.8 release ships four new maintenance tools, and they all share one unusual design decision: none of them scan your disk. They ask an index that's already there.
The tool that was secretly an engine
Back in 1.0.5 I wrote about replacing Everything with a homegrown search engine: read the NTFS Master File Table directly, store the metadata columnar, snapshot it to disk, load via mmap. The resident index for a million-plus files ended up at a few megabytes, and queries stayed Everything-compatible.
That engine runs as a Windows service. The service holds the volume handles (reading raw $MFT needs more than a standard user token), keeps the snapshots fresh from the USN journal, and answers queries over named pipes. The GUI never elevates.
For a year, that service had exactly one consumer: the file search window. Which always felt a bit wasteful. A fresh MFT snapshot is effectively a complete catalog of every file on your disk — the treemap above is 533 GB across 1,108,909 files, drawn before you could have finished reading a progress bar. Every disk utility that starts by walking directory trees is re-deriving information the index already has.
So 1.0.8 is the release where three new tools stopped deriving it.
Consumer #1: the disk analyzer that never scans
Space analyzers are famous for their progress bars. WinDirStat, TreeSize, all of them — you launch it, pick a drive, and watch a tree walk grind through a few hundred thousand directories before anything useful appears.
Ours has no progress bar because there's nothing to watch. The analyzer sends a dirsize query to the service and gets sizes back from the snapshot — a first pass over a volume is the time of one IPC round trip. "Drilling down" is just asking about a subdirectory, which is another round trip. The client keeps no state at all; there's nothing to invalidate when files change, because nothing was cached.
The interesting UI part is a squarified treemap (Bruls et al. — the layout algorithm, not a vibe). Folder area is proportional to bytes, anything below 0.75% of the view gets merged into an "other" tile so the map stays readable. Right-click gives you recycle-bin delete, permanent delete, copy path, or open in Explorer — and the delete path validates that the target is inside the current result set before it acts, because a treemap tile is a view of data, not a file handle.
Consumer #2: the file cleaner with a budget
The new cleaner covers 152 rules in eight categories: system, browsers, apps, AI tool caches, containers, development artifacts, project build outputs, and a "large files" bucket that's really a size:>50MB aggregate query grouped by extension. That last one is a good example of how rules and queries blur: a rule that would take a recursive scan minutes is, over the index, one aggregate call.
The scan reuses the service's dirsize/aggregate queries. No directory walk, no per-file stat() storm.
One design choice I want to defend: this cleaner deletes permanently. It does not use the recycle bin, because cleaning 8 GB of build artifacts into the recycle bin doesn't clean anything — it just renames the problem. But permanent deletion needs to earn trust, so it runs behind four gates:
- Whitelist roots — five built-in roots plus detected project roots are never touched.
- Protected segments — name-level protections, including chat application database files (the ones that hold your message history).
- Reparse points are never followed or deleted — a junction or symlink is a boundary, not a shortcut through it.
- Process re-check — if a rule targets an app's cache, the app must not be running before its files go.
Riskier rules ship unchecked by default. The checklist has three-state semantics (parent / partial / all), the list goes read-only mid-clean, and you can stop at any time — the report logs what it stopped with, honestly, as "stopped".
Consumer #3: the search window grew a native UI
The file search window itself moved from WebView2 to ImGui on DX11. Nothing against the browser engine, but a search results list wants to scroll a hundred thousand rows without caring, and Dear ImGui does that on a UI thread that sleeps in WaitMessage when nothing is happening. The window now follows the system theme and language in real time — it listens for the same ImmersiveColorSet broadcast Windows sends when dark mode flips.
The engine underneath didn't change: bigram inverted index, USN catch-up, 5–30 MB resident. The status bar in the screenshot below is the whole pitch in one line — search service online (live index), results: 255 (155 ms).
The plumbing nobody sees but everybody feels
Three front ends plus the existing batch tools now hit one service over named pipes. The concurrency model matters more than it sounds: interactive searches get their own slot, and heavy queries (dirsize/aggregate) get three more, assigned to client processes LRU-style so a third tool degrades gracefully instead of colliding. The two groups never preempt each other — a long cleanup scan can't abort your ad-hoc search, and vice versa; within a slot, a newer request from the same client replaces its own stale one, which is exactly the "user already typed something else" case.
One subtlety worth keeping: the front end can't distinguish "indexed" from "truth" — the snapshot is only as fresh as the last USN catch-up. For search that's fine. For a tool that's about to delete files, it isn't, which is why the cleaner re-validates through the normal filesystem layer before anything destructive, and why the analyzer's delete path confirms the target exists where the treemap says it does.
flowchart LR
A[FileClean rule] -->|"aggregate query"| S[Named pipe]
B[DiskSpace drill-down] -->|"dirsize query"| S
S -->|"own slot per group<br/>no cross-preemption"| C[Service answers<br/>from mmap snapshot]What I'd take from this
The general lesson, if there is one: when you own an index, every new tool has a much shorter spec. The cleaner's "scan" feature is a query. The analyzer's entire engine is an IPC client. The hard part — reading NTFS fast, storing it small, keeping it fresh — was paid once, and four tools now amortize it.
There's a product lesson in there too. 1.0.8 looks like "four new tools" in a changelog, but from the inside it's one capability (a resident disk catalog) finding three more users. If you're building a suite, the features that compose like this are worth more than the ones that bolt on.
yyzTools 1.0.8 is free, no account, no telemetry — the analyzer and cleaner work entirely from local data, and the only network calls in the suite belong to features that inherently need one (like web translation). Windows 10/11, 12 languages, at yyztools.com. Happy to answer questions about the treemap layout, the IPC slot design, or the safety model in the comments.
Top comments (0)