Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
When a desktop search engine keeps a persistent index of the file system and exposes it as a local service, new utilities stop needing their own file scans. They become clients of that index. The yyzTools 1.0.8 release is a case study of this pattern: its file search window, a disk analyzer, and a file cleaner all query one shared index service rather than walking the disk separately. “Four tools” counts the existing search window plus three maintenance tools added alongside it.
The description below comes from the yyzTools builder’s own account in a DEV Community post dated September 18. The post does not show a year in the text, and the performance and design figures are the author’s self-reported claims, not independently measured results.
How the shared index is built
According to the author, an earlier yyzTools release replaced Everything, a widely used Windows search tool, with a homegrown search engine. The engine reads NTFS Master File Table (MFT) metadata directly, stores that metadata in a columnar layout, and writes snapshots to disk. At startup it loads those snapshots through memory mapping, and it uses the NTFS USN change journal to bring the snapshot up to date as files change.
The engine runs as a Windows service. The service holds the volume handles and answers queries over named pipes, so the user-facing window does not need to be elevated. The author gives a resident index size of 5–30 MB, which is the figure to keep in mind when weighing the design: the index is small enough to stay in memory while serving several front ends.
#1 Best Overall
Why a service, not a library
Putting the index behind a service is what makes the platform idea work. Each front end sends a query and receives results; none of them needs direct access to the MFT, the journal, or the snapshot files. That separation is also what allows a new tool to be added without re-implementing the hard parts.
Four tools on one index
File search window
The search window is the original consumer. In 1.0.8 its interface moved from WebView2 to Dear ImGui on DirectX 11. The author states that the underlying engine did not change. The engine uses a bigram inverted index, and when the window opens it catches up on recent changes from the USN journal. The rewrite changed how results are drawn, not where they come from.
Disk analyzer
The disk analyzer asks the service for directory sizes computed from the index snapshot. Drilling into a folder is another query to the same service, not a fresh walk of that directory. Results are shown as a squarified treemap. The author says items below 0.75% of the visible area are grouped into a single “other” tile, which keeps small items from crowding the view.
File cleaner
The file cleaner checks 152 rules across eight categories: system, browser, application, AI tool cache, container, development artifact, project build output, and large files. The large-files category is an aggregate query: the service returns files over 50 MB, grouped by extension. The other categories use the same index to locate candidates before any deletion is considered.
Rank #2
Batch tools
The author also says batch operations draw on the same service, so a scripted job and the interactive window send their requests to the same place rather than each keeping its own copy of the file list.
Keeping interactive queries responsive
Directory-size and aggregate queries can be much heavier than a name search. The author describes a concurrency design that keeps them from blocking the interactive experience:
- Interactive searches and heavier directory-size or aggregate queries are handled in separate groups.
- The heavy group has three slots. A slot is assigned to a client process on an LRU (least recently used) basis.
- The two groups do not preempt each other, so a long analysis does not stall a keystroke-level search, and a search does not cancel an analysis.
- If a client sends a new heavy request while one is already waiting in its slot, the newer request replaces the stale one.
These are design choices described by the author. The article does not include load tests showing how the groups behave under contention, so the mechanism is clear but its real-world effect is not measured.
Why reuse is the central point
The author’s summary of the design is short: “when you own an index, every new tool has a much shorter spec.” The reasoning is that the difficult work, reading NTFS quickly, storing the metadata compactly, and keeping it current, is done once. Each later tool then needs to specify only what it asks and how it shows the answer.
Rank #3
The same idea appears in the author’s phrasing that the hard part “was paid once, and four tools now amortize it.” Whether that trade is worthwhile depends on how many tools reuse the service and how much each one would otherwise have had to build.
Scanning versus querying a shared index
- Repeated scanning: each tool walks the disk, pays its own I/O cost, and keeps its own view of the file system.
- Shared index: one service keeps a snapshot current and answers many queries, so tools differ mainly in the questions they ask.
- Cost of the shared approach: the service has to expose a stable query interface and must be maintained as the front ends evolve.
Safety: an index is a view, not the current state
The most important limit of this design is freshness. The author puts it directly: “the front end can’t distinguish ‘indexed’ from ‘truth’ — the snapshot is only as fresh as the last USN catch-up.” A file can be moved, renamed, or replaced between the last update and the moment a user acts on a result.
For that reason the author’s design uses the index for discovery and then checks the filesystem before anything is removed. The cleaner’s safeguards, as described, include:
- Five built-in whitelist roots, plus detected project roots.
- Protected path segments, including the databases used by chat applications.
- Refusal to follow or delete reparse points, such as junctions and symbolic links.
- A check that an application is not running before its cache is cleaned.
- Riskier rules left unchecked by default.
The cleaner deletes permanently rather than sending files to the Recycle Bin. During a clean the candidate list becomes read-only, and the user can stop the operation. The author says deletion goes through the normal filesystem layer, and the analyzer’s delete path confirms that the selected target still exists where the treemap indicates.
Deletion sequence described by the author
- The index proposes candidates from a rule or a directory-size query.
- The candidate list is shown with riskier rules unchecked by default.
- On execution, reparse points and protected segments are excluded, and running applications are detected before their caches are touched.
- Each target is revalidated through the filesystem immediately before removal.
- The user can stop the run while it is in progress.
A reader should treat these steps as the author’s account of intended behavior. The article does not report a failure-mode test of the revalidation step.
The figures, and what they do and do not show
All numbers in the post come from the yyzTools author, not from an outside measurement:
- Resident index size: 5–30 MB.
- Example treemap coverage: 533 GB and 1,108,909 files, from one example in the post.
- Cleaner rules: 152 rules in eight categories.
- Large-file threshold: files over 50 MB.
- Treemap grouping threshold: 0.75% of the view.
The post is dated September 18 without a year in its text. The figures describe one machine and one example, so they show what the design produced for the author, not how it performs on other hardware or across typical user setups.
Version, platform, and availability
The article identifies the release as yyzTools 1.0.8. The author describes the toolkit as free, local-first, available for Windows 10 and Windows 11, and offered in 12 languages. The author says the suite has no account requirement and no telemetry, and that network calls are used only for features that inherently need them, such as web translation.
These are product claims made at the time of the post. Check the project’s current release notes before relying on version, language, or privacy details, since they may have changed.
Where the pattern holds, and where it does not
The yyzTools case supports a narrow conclusion. A persistent, incrementally updated index, served locally, can cheaply support several tools that would otherwise each scan the disk. It also makes the cost of new tools lower, provided the service interface stays stable. The article does not show that the approach is faster or safer than independent scanning in general, and it does not compare yyzTools with other products.
The approach fits best when several tools need the same view of the file system, when the view can be refreshed from a change journal, and when destructive actions can be checked against the filesystem before they run. It fits less well when a tool needs guaranteed real-time state at every step, or when there is only one tool and no reuse to amortize the index’s cost.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsQuick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
