A fast, local filename search for Windows 10 and 11 with a built-in preview pane. It keeps its own index of file and folder names in SQLite, so searching never scans the disk: typical queries over 1.6 million entries answer in 1–30 ms (see docs/BENCHMARKS.md).
Local-only: no cloud services, telemetry or accounts. Runs without administrator rights.
- Instant substring search on names (case-insensitive, Unicode), with extension, file/folder and full-path filters.
- Search scope: everywhere, your Desktop/Documents/Downloads…, any indexed location or any folder you pick. Right-click a result for "Search in this folder" or "Hide this folder from results".
- "Hiding system & app data" (on by default) keeps AppData, Windows,
ProgramData, dot-folders such as
.git/.vscode,node_modulesand similar out of results. They stay indexed; one click shows them again. - Preview pane, rendered in the background for the selected file only:
- images, zoomable (wheel, Ctrl +/−, drag to pan, double-click to fit) with a sharper rendering loaded when you zoom in;
- PDF pages, zoomable, with page navigation (Windows' built-in PDF engine, run in an isolated helper process);
- Word (.docx) and Excel (.xlsx) documents without Office installed, zoomable, with sheet tabs;
- text and source code, folders, and file details plus the Windows thumbnail/icon for everything else.
- Rename a result in place: F2 or right-click > Rename. The index and the list update at once; invalid names, existing names and access problems are explained under the name. Nothing is renamed until you press Enter.
- Resizable columns: drag a divider in the header to resize the column on its left; double-click a divider to reset. The widths are remembered.
- Live index updates while the app runs, background reconciliation for changes made while it was closed, resumable initial indexing, and a status bar that says whether the index is up to date.
- Dark, keyboard-first interface.
| Key | Action |
|---|---|
| type | search immediately |
| ↑ / ↓, PageUp / PageDown, Ctrl+Home / Ctrl+End | move the selection |
| Enter | open with the default app |
| Ctrl+Enter or Ctrl+E | show in Explorer |
| Ctrl+C | copy the selected path (or the selected text in the search box) |
| F2 | rename the selected file or folder (Enter renames, Esc cancels) |
| Ctrl + / Ctrl − / Ctrl 0 | zoom the preview / reset |
| Ctrl+PageDown / Ctrl+PageUp | next / previous PDF page |
| F5 | refresh results |
| Ctrl+, | settings |
| Esc | clear the search; close the window when it is already empty |
| Example | Meaning |
|---|---|
report 2024 |
names containing both words |
"annual report" |
a term with a space |
*.pdf or ext:pdf,docx |
extension filter |
folder: / file: |
only folders / only files |
src\main or path:projects |
match anywhere in the full path |
- Windows 10 or 11, x64.
- To build: stable Rust (tested with 1.93) with the MSVC toolchain
(
rustup default stable-x86_64-pc-windows-msvc) and the Visual Studio Build Tools (C++ workload, for the linker). SQLite is compiled from the bundled sources; nothing else needs installing.
cargo build --release
.\target\release\winsearch.exe
cargo test --release
powershell -ExecutionPolicy Bypass -File scripts\package.ps1The release executable is target\release\winsearch.exe. The packaging
script tests it and copies it to dist\WinSearch-<version>\winsearch.exe,
one folder per release containing only the program. It is portable (no
installer, copy anywhere).
winsearch.exe --query "text" starts with a search filled in;
--scope C:\path starts inside a folder.
Sample files for trying the previews:
powershell -ExecutionPolicy Bypass -File scripts\make-samples.ps1.\target\release\wsctl.exe index --db C:\temp\idx.db C:\Users # build an index
.\target\release\wsctl.exe search --db C:\temp\idx.db report ext:pdf
.\target\release\wsctl.exe bench --db C:\temp\idx.db # compare search strategies
.\target\release\wsctl.exe walk C:\ # enumeration speed only
.\target\release\wsctl.exe preview C:\path\file.pdf # preview latency
.\target\release\wsctl.exe check --db C:\temp\idx.db # integrity checkWithout --db, wsctl uses the app's own index.
On first start WinSearch indexes every ready local fixed drive (skipping
$Recycle.Bin and System Volume Information). You can search while it
runs; the status bar shows progress, unreadable folders and a Cancel
button (a cancelled scan picks up where it stopped on the next start, or from Settings > Index status). Change locations,
exclusions and options in Settings (gear icon or Ctrl+,).
| Index | %LOCALAPPDATA%\WinSearch\index.db (+ -wal/-shm) |
| Settings | %LOCALAPPDATA%\WinSearch\config.json |
| Logs | %LOCALAPPDATA%\WinSearch\logs\winsearch.<date>.log (7 days kept; set WINSEARCH_LOG=debug for more) |
| Crash reports | winsearch-crash-<time>.txt next to winsearch.exe (or in the logs folder if that folder is read-only) |
Set WINSEARCH_DATA_DIR to use a different folder. Deleting the folder
resets everything; Settings > Index status > Rebuild does the same for
the index only.
Nothing requires elevation. Without it, live updates come from Windows change notifications and a background reconciliation scan at startup (and every 6 hours) catches anything missed. When WinSearch is run as administrator, drive roots on NTFS/ReFS use the NTFS change journal instead: changes made while the app was closed are replayed without a rescan. The app never creates, resizes or deletes a change journal and never changes file-system settings. Settings > Locations shows which mode each location uses and why.
WinSearch never modifies, moves or deletes your files. The only change it makes is a rename you type yourself (F2), which never replaces an existing item. Otherwise it only reads directory listings and, for the selected file, its contents.
If WinSearch crashes, it writes winsearch-crash-<time>.txt next to the
executable and, for errors in its own code, says so in a message box. The
report holds the version, the Windows build, what you were doing (for
example which file was being previewed), and either the error with a stack
trace or, for a native crash, the exception code and the DLL it happened
in. A DLL that is not winsearch.exe means another program's component
(for example a shell extension or PDF handler) crashed inside WinSearch.
The report contains file paths but nothing else from your files.
When you preview a PDF or a file type that needs a Windows thumbnail,
WinSearch starts a second copy of winsearch.exe with the argument
--render-preview. It has no window, renders that one page or thumbnail,
passes the image back to the main window through a pipe and exits, usually
within a second. This keeps crashes in Windows' PDF engine or in other
programs' thumbnail handlers from closing the search window. It is the same
file you started, never a downloaded or extracted one.
Microsoft Defender has flagged WinSearch builds as
Trojan:Win32/Bearfoos.B!ml. The !ml suffix means a cloud
machine-learning guess, not a match against known malware; new, unsigned
programs that nobody else has run yet, that read the whole disk and that
start copies of themselves are typical false positives. WinSearch has no
network code, no installer, no packer or obfuscation, and its full source
is in this repository.
The executable carries version information, an application manifest (normal user rights, no elevation) and an icon, so it describes itself to Windows. That helps but guarantees nothing. What actually helps:
- Report the false positive at
https://www.microsoft.com/wdsi/filesubmission: choose "Home customer"
(or "Software developer" with a Microsoft account), product "Microsoft
Defender Antivirus", upload
winsearch.exe(zip it if the browser blocks the upload), select "Incorrectly detected as malware/malicious", and give the detection name and the link to this repository. Microsoft usually answers within a few days and the fix reaches other PCs through definition updates (Update-MpSignaturespeeds that up). - Sign the executable with a code-signing certificate (for example Azure Trusted Signing or an OV/EV certificate). Signed files build reputation across versions; unsigned ones start from zero with every build.
To check a build locally:
& "$env:ProgramFiles\Windows Defender\MpCmdRun.exe" -Scan -ScanType 3 -File <path>\winsearch.exe.
- docs/ARCHITECTURE.md: index schema, scanning, change tracking (USN vs notifications vs rescans), preview isolation, why Shell preview handlers are not hosted in-process.
- docs/BENCHMARKS.md: indexing speed, search latency by strategy, memory, preview latency, with the test machine and dataset.
- The NTFS change journal is only used when running elevated and only for whole drives; folder roots and non-admin sessions rely on notifications plus reconciliation scans (about 45 s of background disk reads for 1.6 M entries).
- The USN journal reader is covered by unit tests of its record parser and availability checks, but was not exercised end to end on the development machine (no elevation available there).
- One- and two-character searches use name prefixes plus a bounded substring scan, so their result count is approximate ("5,000+").
- Office previews show text, headings, lists and tables only (no images, styling or formulas; Excel shows stored values, so dates appear as serial numbers). Legacy .doc/.xls files fall back to the Windows thumbnail.
- PDF previews take ~0.3 s because each render starts an isolated helper process; password-protected PDFs are not previewed. On some machines with third-party PDF software installed (seen with WPS Office), Windows' PDF engine crashed while shutting down after rendering; since 0.1.1 the helper delivers the page first and exits without that cleanup, and a crashed render is retried once from an in-memory copy of the file.
- File names that are not valid UTF-16 (unpaired surrogates) are stored in a lossy form.
- Network drives are scanned like local ones; change notifications on them depend on the server.