Eidos: A Windows-first filesystem catalog that separates paths from identity

What Eidos is actually trying to solve

Eidos addresses a specific frustration: file search tools force you to answer the location question before you can search. You have to remember which machine, which VM, which archive, or which network share held the file. The README describes this as a product vision where the machine a file lives on no longer determines where you search. The intended audience is someone who manages multiple computers, servers, virtual machines, and archives, and who often remembers content or context but not names or paths. The project is Windows-first, written in Rust, with SQLite for the catalog and Tantivy for search. It is not a cloud service; it is self-hosted and private. The README is unusually honest: it states clearly that this is a product vision draft and that several capabilities are planned rather than available today. There is no packaged release yet, and APIs, schemas, and query syntax may change. That framing matters because it sets expectations for anyone evaluating the project.

The core architectural idea: paths are not identity

Most indexing systems treat a path as the file's identity. Eidos separates the two. It maintains a canonical catalog of filesystem objects and models paths separately. That means a rename is a rename, not a deletion followed by the discovery of unrelated new content. This is a meaningful design choice because it affects how the index behaves when files move, are hard-linked, or are observed from multiple sources. The README says search indexes, hashes, snippets, aggregates, and relationships are derived views that can be rebuilt without losing the underlying truth. That is a strong architectural stance. It suggests the durable catalog is the source of truth, and the search index is disposable. For a tool that aims to search across systems that may be offline, this separation is what allows the system to preserve the last known state of an unavailable source. If the path were the identity, a powered-off machine would make its files disappear from the catalog entirely.

Directories as first-class searchable results

Eidos treats directories as more than containers. They are searchable results with properties of their own. The README lists concrete query types: directories containing particular combinations of file types, trees above a given apparent or allocated size, folders with more than a specified number of files, and directories whose newest descendant changed within a time range. This is a different approach from typical file search, which returns files and maybe folders as metadata. The ability to search by subtree shape is useful for finding a project when you remember it had a config file and a diagram, but not the project name. The README also mentions planned support for exact and near copies of directory trees. That is not yet available. The current implementation may support some of these queries, but the README does not specify which ones are live. That is a gap you need to verify in the roadmap.

Searching inside archives and powered-off VMs

One of the more ambitious claims is the ability to search inside archives and, later, virtual disks without unpacking them or booting the guest. The README says supported archives can be searched without being unpacked into the source tree, and planned virtual-disk support will make files inside VHDX images discoverable from the host. There is a resource limit mechanism: limits follow the entire nested operation, so corrupt archives, extreme compression ratios, and unexpectedly large contents cannot silently consume unbounded memory or storage. That is a sensible safety feature, but it is also a hard engineering problem. Parsing archives and disk images in Rust is doable, but handling every format variant and corruption case is not trivial. The README does not say which archive formats are supported today. That is another thing to check. The virtual disk feature is explicitly planned, not available.

Freshness and coverage as part of the answer

Eidos reports coverage with every response: which sources are complete, pending, stale, degraded, or offline. This is a genuine differentiator. Most search tools either return results or return nothing, without telling you what was searched. Eidos aims to make a zero-result page meaningful by telling you what was actually searched. The README also describes a planned fleet architecture where available machines can confirm, update, or retract results as fresher information arrives. That means answers can converge over time instead of waiting for the slowest source. The freshness of a result is part of the result itself. This is a good design for a multi-machine environment, but it also adds complexity. The README says this is planned, so you should not expect it in the current build.

Getting it running and what to expect

The README does not provide installation commands or configuration keys. It says there is no packaged release yet. That means you cannot simply download a binary. You would need to build from source, assuming the repository contains a build process. The project uses Rust, SQLite, Tantivy, and React. Tantivy is a search library, SQLite is the catalog store, and React likely powers a web interface. The exact commands to build and run are not in the README. You would need to clone the repository and inspect the build files, such as Cargo.toml, to figure out the binary name and any configuration. The README explicitly warns that APIs, schemas, and query syntax may change. So even if you get it running, expect breakage. The license is AGPL-3.0, which has implications if you want to use it as part of a service you offer to others. That is not legal advice, but you should be aware that AGPL requires source disclosure for network services.

Limitations and when Eidos is the wrong tool

The most obvious limitation is that most of the README describes a future state. The project is under active development, and several capabilities are planned rather than available. If you need a working search tool today, Eidos is not it. The README also says it is Windows-first, so if you are on Linux or macOS, this may not be usable at all. The resource limit mechanism is described, but there is no evidence it is fully implemented. The fleet architecture is planned, not real. So the 'search across systems as though everything were local' promise is aspirational. Another limitation is that the README does not mention how it handles encryption, permissions, or files that change while indexing. Those are real-world concerns for a catalog that claims to maintain a durable understanding of what exists. The wrong use case is a single-machine user who just wants fast desktop search; there are simpler tools for that. Eidos is aimed at a multi-system, multi-archive scenario, and even then, only once the planned features land.

Alternatives and how they differ

A real alternative is Everything, a Windows desktop search tool that indexes filenames and provides near-instant results. Everything is fast and lightweight, but it searches filenames only, not content, and it stops at the local machine. It does not model paths separately from identity, so a rename appears as a delete and an add. Another alternative is a storage analyzer like WinDirStat or WizTree, which show where space went but do not search content or relationships. Eidos differs from both by separating path from identity, searching inside archives, and reporting freshness. There is also the option of using a general-purpose content search like ripgrep, but that requires you to know which directory to search. Eidos aims to remove that requirement, but it is not yet there. The closest conceptual comparison is a personal search engine like DocFetcher, but DocFetcher indexes local files and does not handle multiple machines or offline sources. The key difference is Eidos's canonical catalog and the separation of paths from identity, which no mainstream desktop search tool offers.

Editorial conclusion

Adopt Eidos now only if you are comfortable with a pre-release tool, you need a Windows-first catalog that models paths separately from file identity, and you can tolerate API and schema changes. Do not adopt it if you need cross-platform support or the planned fleet and virtual disk features today. Before using it, verify which of the README's scenarios are actually implemented by reading docs/roadmap.md and the 'What works today' section, and confirm the current query syntax and index format, since the README warns they may change.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes