Lertaro: NTFS MFT and USN Journal Search for Windows

The Windows search problem Lertaro is aimed at

Windows Search builds its index by crawling directories and reading file metadata through the filesystem API. On a large drive with millions of files, that crawl is the cost you pay for every reindex, and the index it produces can lag behind what is actually on disk. Lertaro takes a different route. According to the README, it reads the NTFS USN Change Journal and the $MFT directly instead of walking directories, so the index is derived from records the filesystem already maintains. The README describes the result as "near-instant, low-resource search" and positions the project as a modern open-source alternative to Listary and Everything.

The audience is narrow and specific. This is a Windows-only tool, built on .NET 10 with WPF, and the README lists Windows 10 and Windows 11 as the build requirements. It is for people who already use a keyboard launcher and want file search in the same surface: the README describes three window modes, one of which is an inline bar that docks into native Open and Save dialogs and into File Explorer, Total Commander, Directory Opus and OneCommander. If you search for files by typing a few characters rather than browsing a tree, that is the workflow being targeted. If you mostly work on macOS or Linux, or your files live on a NAS mounted over SMB, the mechanism the project is built around does not apply to you.

How the MFT and USN Journal indexing actually works

The core mechanism is a background service. The README names three processes: `Lertaro.Service`, described as a SYSTEM background service, `Lertaro.App`, the user-mode WPF UI, and `Lertaro.Service --hook`, a helper that the README says bypasses UIPI. The README calls this arrangement "3-process isolation" and states the three are strictly isolated. That matters because the service runs as SYSTEM to read the low-level NTFS structures, while the UI runs in your session, and the hook helper exists because a user-mode process cannot inject into an elevated window without a privilege boundary being crossed.

The index itself comes from the $MFT, the master file table that holds a record for every file and directory on an NTFS volume, and from the USN Change Journal, which records changes as they happen. Reading the journal means the service can keep the index in sync in real time rather than rescanning. The README also states that the project handles FAT32 and exFAT monitoring and network share caching, which is a different path from the NTFS read. That distinction is worth holding onto: the low-level mechanism described in the highlights applies to NTFS and ReFS, and the other filesystem types are described as monitoring rather than MFT parsing.

On top of the index sits a query layer. The README describes "fzf-Style Fuzzy Search & Aliases" with multi-keyword jump matching, directory path tokens, prefix, suffix, exact and exclude operators, and non-ASCII pinyin alias transliteration. There is also a disk space Treemap that the README says works from the index without rescanning disks, and a plugin SDK with contracts for custom search providers, aliases, actions, columns and previews.

Installing Lertaro and running a first search

The README gives two x64 download paths and two ARM64 paths. The installer is named `Lertaro-Setup.exe` for x64 and `Lertaro-Setup-arm64.exe` for ARM64, and the README says the installer is recommended because it supports the background service. The portable builds are `Lertaro-Portable.zip` and `Lertaro-Portable-arm64.zip`, described as unzip and run with no install. The README carries a security notice telling you to download only from the official repository, website and GitHub Releases. Take that literally: the project has no code-signing claim in the README, so the only assurance the page offers is provenance.

If you build from source instead, the README lists the requirements as Windows 10 or 11, the .NET 10 SDK, Visual Studio 2022 or JetBrains Rider, and the 64-bit edition of Inno Setup 7 if you want to produce an installer. Two batch files are named. `build_and_run.bat` rebuilds App, Core, Service and plugins and relaunches everything locally. `make.bat` produces Release builds for x64 and ARM64 into `dist/`.

The repository also contains `install-dotnet-runtime.bat`, which suggests a path for machines that do not already have the runtime, though the README does not document what that script does in detail. The install commands below are the ones the README names, written as you would run them from a shell.

build_and_run.bat

Running that rebuilds the four project groups the README lists and relaunches the app. You should see the WPF UI start and the background service come up alongside it.

make.bat

That produces Release output for both architectures under `dist/`. The README does not state what the folder layout inside `dist/` looks like, so check it yourself before wiring it into a release pipeline.

Once running, the README names two hotkeys worth trying first. `Ctrl+O` opens the actions menu, which the README says integrates with the native Shell right-click menu. `Alt+P` opens a QuickLook file preview. For search syntax, operator list and the full hotkey table, the README points at the user manual on the project site rather than reproducing them, so the README alone is not enough to learn the query language.

Where Lertaro stops being the right tool

The mechanism is the limitation. Everything fast about Lertaro rests on the NTFS $MFT and USN Journal. The README states that FAT32 and exFAT get monitoring and that network shares get caching. Neither of those is the same as reading the master file table, and the README does not claim equivalent latency for them. If your working set is on a USB stick formatted exFAT, or on a mapped network drive, you are not using the path the project is designed around, and you should not expect the same behaviour. ReFS is mentioned alongside NTFS in the indexing highlight, but the README does not break down which ReFS features are supported.

There is a second boundary. A SYSTEM service that reads low-level filesystem structures is a different security proposition from a user-mode indexer. The README addresses this with the three-process split and with a zero-telemetry, fully local claim, and it explicitly names the UIPI-bypassing hook helper. That is honest labelling, but it is still a service running with high privilege. If your environment forbids SYSTEM-level background services, the portable build is the alternative, and the README implies the portable path does not install the service.

Third, the release cadence is dense. Three releases are listed, v5.6.5, v5.6.6 and v5.6.7, all dated 2026-09-14 and 2026-09-15. That tells you changes land quickly, and it also tells you the surface you validate today may move next week. The README does not document rollback, downgrade or uninstall procedures at all, which is the gap I would press on hardest before deploying this on a machine you cannot easily rebuild.

Lertaro against Everything and Listary

The README names both Everything and Listary as the tools Lertaro is an alternative to, and the topics list repeats both names. The comparison that matters is architectural, and the README gives enough to draw it.

Everything is the reference point for MFT-based search on Windows, and Lertaro's indexing highlight describes the same underlying source, the USN Journal and $MFT. Where Lertaro departs is in scope. Everything is a search tool. Lertaro is a launcher that also searches: the README describes an actions menu bound to `Ctrl+O`, an `Alt+P` preview, an inline bar that docks into Open and Save dialogs, a Treemap for disk usage, and a plugin SDK. That is a broader product with a correspondingly larger surface to trust.

Listary is the closer comparison, because Listary is also a launcher that hooks into file dialogs. Lertaro's answer is the `Lertaro.Service --hook` helper and the docking list, which the README gives as File Explorer, Total Commander, Directory Opus and OneCommander. The README also claims compatibility with Flow Launcher community plugins, which is an ecosystem bridge rather than a from-scratch plugin market. If your existing plugin investment is in Flow Launcher, that line is the one to test.

The honest difference is not speed, since the README makes no benchmark claim for any of the three. It is that Lertaro is MIT licensed and open source, so the indexing and hook code is inspectable, and that it is a single project covering search, launch, preview, disk usage and plugins rather than a focused search index.

Licence, upgrades and the cost of keeping up

Lertaro is MIT licensed. That is a permissive licence: you can use, modify and redistribute it, including in commercial settings, provided the copyright notice and permission notice are retained. The README does not add any field-of-use restriction, and it does not mention a contributor licence agreement or a separate commercial tier. The README does include a donation address, which is unrelated to licensing. None of this is legal advice; if you are embedding the code in a product, read the LICENSE file in the repository root yourself rather than the README summary.

The upgrade picture is where the cost sits. The README documents `portable-updater.bat` and `portable-cleanup.bat` as top-level repository entries, which suggests the portable build has a defined update path, but the README text does not describe what either script does or whether the installer build updates in place. There is no documented rollback, no migration note and no compatibility statement for the plugin SDK across versions. Combined with three releases in two days, that means an unattended update policy is a risk you are taking on without documentation.

The repository layout shows a `Tests/` directory, so the project carries tests, but the README does not state coverage or which layers are covered. The last push to the repository was on 2026-09-15, and the most recent release, v5.6.7, carries the same date.

Editorial conclusion

Adopt Lertaro if you work on Windows 10 or 11 with NTFS system drives and want a local, MIT-licensed launcher that reads the MFT and USN Journal rather than walking directories, and if you can accept that the README does not document rollback, uninstall behaviour or upgrade steps. Do not adopt it if your data lives on exFAT or FAT32 volumes, on network shares, or on ReFS volumes you expect to be indexed at the same level, since the README describes those paths as monitoring and caching rather than the low-level read used for NTFS. Before committing, verify three things yourself: that a portable build runs correctly on your machine, that the background service installs and starts under your account, and that the plugin SDK contracts you depend on exist in the version you download.

Frequently asked questions

Official sources

1. Lertaro/Lertaro on GitHub
2. License: MIT
3. Project website
4. README
5. Releases