OmniSearch: a Windows file search that reads the filesystem's own records

Asking the filesystem instead of walking it

OmniSearch is described as a fast Windows desktop file search built with Tauri v2, Rust, and C++, and the sentence that explains how it is fast is the second one: it reads NTFS metadata directly through the USN and master file table APIs for quick global search, advanced filters, duplicate cleanup, and keyboard-friendly workflows.

Every file search tool on a desktop does one of two things. The slow way is to walk the directory tree and ask the operating system for the contents of each folder, which means an enormous number of small requests and a result that arrives at the speed of the disk's metadata operations. The fast way is to ask the filesystem for a list of everything it knows, which the NTFS master file table already holds, and then to keep that list current.

The change journal is the second half of the idea, and it is the more interesting one. NTFS keeps a journal of changes to the filesystem, a record of every file created, renamed, and deleted. A program can watch that journal and update its index as things happen, rather than rescanning. So the readme's feature list describes live incremental index updates via the journal watcher after the initial scan.

That is the same idea as the file system indexes that operating systems ship, and the same idea as the search index of a source control system, applied at a different level. It is also why the tool is fast in a way that a directory walker cannot be: the initial scan is one operation against a structure the filesystem maintains anyway, and everything after that is a stream of change records.

The user-facing consequence is in the interface. Search results come back with filters for extension, file size range, and created date range, with clear buttons for each, and a compact layout toggle, and the whole thing is designed around a keyboard rather than around a mouse. That last part is a design decision with a technical reason behind it: a search tool is used in bursts, and a burst is faster with a hotkey than with a click.

The project is MIT licensed, the last push was on 2026-08-21, and the release history is a pre-1.0 line with several releases in the summer of 2026.

Three languages, and what each one is for

The feature list describes the architecture in three layers, and the division of labour is the interesting part.

The bottom layer is a native Windows indexing engine written in C++, and it works through the device control interface and the enumeration of the master file table and the change journal. That is the layer that has to talk to the operating system's internals, and C++ is the right choice for it because the interface is a system call boundary with a cost per call.

The middle layer is a foreign function interface bridge in Rust, and the readme lists what it exposes to the layer above: commands for indexing, for searching, for duplicates, for drive listing, and for file actions. So the Rust layer is a narrow, typed boundary between the native engine and the application, and it is the layer where the C++ interface stops being an operating system call and becomes a set of operations the interface can use.

The top layer is the application, and it is the one the user sees. The feature list describes the interface as a fast search with advanced filters, the quick window mode, the duplicate finder, the recent activity list, the theme gallery, and the result actions. The repository layout confirms the split, with a directory for the native side, a directory for the bridge and the application commands, a front end directory, and a separate directory for the second, smaller product.

The front end is a React application built with Vite, and the manifest is small enough to read in one go.

  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview",
    "tauri": "tauri"
  },

The three development commands are the usual Vite pair plus one that hands over to the Tauri command line, and the build script compiles the TypeScript before bundling, which is the correct order and the reason the type definitions are checked at build time rather than at run time.

The framework plugins are the Tauri ones for the application interface, for opening files, for the process, and for the updater. The updater plugin is worth noting in a project that ships signed builds: the ability to deliver a new version without the user visiting a download page is a distribution decision, and the presence of a code signing configuration in the repository says the same thing.

So the three languages are not a curiosity. They are three layers with three constraints: the one that must call the operating system, the one that must be safe and fast between that and the application, and the one that has to draw the interface.

Hybrid search, and the inline content syntax

The search design is the part of the feature list with the most thought in it, and it is described in two features that have to be read together.

The first is the inline syntax. There is a prefix operator for the file extension, and then a family of content operators: one for plain content, one for ANSI encoded content, and one each for the three common UTF encodings, including the big endian one. So you can write a query that says the file must have that extension, and that its content must contain a string, and you can be specific about the encoding if the file is not text in the ordinary sense.

The second is the hybrid flow. The readme describes it as keeping normal path and name lookups fast, and only scanning file contents from disk when you explicitly use the content syntax.

That is the key decision, and it is a good one. Searching for a file by name is a lookup in an index. Searching for a file by what is inside it means reading every file on the disk, which is orders of magnitude more work, and on a spinning disk or a large solid state drive it is the difference between instant and minutes. Making the content search explicit means the expensive operation happens only when somebody asked for it, and the operator who wants to type a word into a search box does not get a full disk scan as a side effect.

The encoding operators are the detail that shows the tool has been used on real data. Text files in the wild are not all UTF-8, and a content search that assumes they are will silently miss files. Giving the user a way to say which encoding to assume, and naming the variants, is the difference between a feature that works and one that works on a clean directory.

There is a separate guide in the repository for this, a document dedicated to content search, which suggests that the feature is the one with the most documentation and therefore the one with the most edge cases.

The rest of the search surface is conventional and well made. There is a drive picker that detects NTFS and checks volume access, an option to widen the scope from the selected drive to all NTFS drives, an option to include folders in the index so that folder paths appear as results, and an advanced settings panel for the default result limit, which is persisted locally.

And the results themselves are treated as first class: previews for images, video and documents, a quick look triggered by the space key, sort modes, category tabs, and an incremental load more that expands by the configured limit step rather than loading everything at once.

Duplicate finding, with progress and a way to stop

The duplicate finder is the feature that the interface section highlights, and the description says it identifies identical files and shows reclaimable space.

The implementation detail that makes it usable is in the feature list: multithreaded hashing, with the results grouped, and the reclaimable size computed for each group. Hashing is the expensive part, because a duplicate finder has to read every file to hash it, and multithreading is what stops that from being unusable on a large disk.

And then the part that is often missing from tools like this: the scan has a live progress percentage, counters for rows scanned and total, a count of the groups found so far, and a cancel button.

That is not a small detail. A duplicate scan over a terabyte of data is a long operation, and a tool that gives you no feedback and no way to stop is a tool that people run once and abandon. The counters also serve a second purpose: seeing that the scan is still progressing tells you it is not stuck, and the cancel support means an accidental scan of the wrong drive is recoverable.

The delete flow is worth noting too. The feature list mentions an optional recycle bin delete flow for both the duplicate cleanup and the standard search results, which is a significant choice. A duplicate finder that deletes permanently is dangerous, and one that sends things to the recycle bin is recoverable. Making it optional rather than mandatory is a reasonable middle, since somebody cleaning up a disk deliberately may want the space back immediately, but the default is the safe one.

The result actions cover the other half of the workflow. You can open a file, reveal it in the folder, copy the path, copy the file name or the full file name, rename it, and delete it. And the drag-out support means you can drag a result row straight into Explorer or another application, which is the kind of thing that makes a search tool fit into the desktop rather than sit beside it.

Two products, and the extra features in the store

The readme is showing two different applications, and the distinction is not cosmetic.

The first is the desktop application: the main search tab with filters, categories, previews and actions, the quick window with instant filters and a keyboard-first flow and a dedicated preview panel, the duplicate finder, the drive scope and indexing controls, the theme gallery, and the recent activity list that remembers both searches and opened items and can pin the important ones to the top. There is also an optional installed application search with real application icons, direct launching, and integration into the recent activity list, which is the spot where a file search tool stops being a file search tool and starts being a launcher.

The second is OmniSearch Lite, and its description is a different product in one sentence: a lightweight, spotlight launcher with circle to search, an artificial intelligence workspace, mobile phone synchronisation, and built-in productivity tools.

So Lite is a spotlight-style launcher rather than a file browser, and it comes with a few extras that the main application does not have. The mobile synchronisation in particular is the interesting one, and the project description names the mechanism: an Android companion, with the repository holding an Android directory and the primary language recorded as Kotlin. The project description calls it synchronisation over the local network.

The distribution is also different for the two. There is a table in the readme whose single cell says the features are only in the store version, with a download button. The Lite application is listed separately with its own store entry. And there is a collapsible section describing preview extras available in the store, namely custom background images for the application and a compact search bar mode, with screenshots of each.

The commercial logic is straightforward and worth spelling out. The store version is the one with the extra features, and the open repository holds the application, the native engine, and the bridge. The circle to search feature, the workspace, and the phone synchronisation are the paid differentiators, and the price of the store listing is what a user pays for them.

The screenshots are labelled by feature, which is how a store listing is normally built, and it is worth noticing that the readme is written for a store visitor rather than for a developer. There is a commands section and an architecture section further down for the latter, but the top of the document is marketing.

The repository, and the files that describe the work

The repository layout is a Tauri project with a few extra directories, and the names of the files are informative.

There is the front end directory, the native side, the second product's directory, and the Android directory. There is a documentation directory holding the images and the architecture diagram, and a public directory for the assets that are served.

And then there are four files whose names tell you what the project considers important. There is a content search guide, which is the document for the feature with the most edge cases. There is a release notes file, separate from the changelog that the release tool generates, which means the notes are written by hand. There is a privacy file, and the presence of one in a file search tool is worth a moment's thought, because a file search tool sees every filename on your disk. And there is a code signing configuration in a directory of its own, which is how a project that ships signed Windows binaries keeps the signing material out of the tree.

The manifest tells you the shape of the build. The front end is a private package with an ES module setting, so it is not published to a registry, and its version number matches the application's release version, which means the front end and the binary are versioned together.

The dependency list is short, which is what you would expect from a Tauri application, because the Tauri runtime provides the operating system integration and the application only needs the application interface, the plugins, and React.

And the build pipeline is the standard Vite one with a type check in front of it, plus the Tauri command that does the real packaging. There is a separate configuration file for the type checking of the node side of the build, which is the usual arrangement when a project has a small configuration script that is not part of the application.

The overall picture is of a small team building a technically serious application: the hard part is the native indexing engine and the search semantics, and the repository is arranged around exactly those, with the store extras, the mobile companion, and the documentation sitting alongside them as separate concerns rather than being folded into the desktop application.

Editorial conclusion

OmniSearch fits a Windows user with a large disk and a slow search, and a developer who wants an application built on the file system's own metadata rather than on a directory walk. It does not fit a user on another operating system, since the indexing engine is native Windows code, and it does not fit somebody who expects content search to be free, because scanning file contents is a separate, explicitly invoked operation. Verify first how much of your disk is indexed, because the search scope can be limited to the selected drive or widened to all of them, and that the volume access checks pass, since reading the master file table needs permissions that a standard user does not have on every volume.

Frequently asked questions

Official sources

1. Eul45/omni-search on GitHub
2. License: MIT
3. Project website
4. README
5. Releases