Everything Result Omissions Hiding Results: How to Fix It

  • Use disable-result-omissions: to confirm whether valid Everything results are being hidden.
  • Correct temporary or saved omissions without rebuilding a healthy filename index.
  • Troubleshoot filters, exclusions, shares, services, and profiles only when omissions are not responsible.

When voidtools Everything suddenly stops showing files that you know exist, the index is not always the problem. In Everything 1.5, Result Omissions can deliberately hide matching items from the result list. The clearest clue is an OMIT indicator in the status bar. This feature is useful for suppressing unwanted results, but an accidental, overly broad, or saved omission can make valid files appear to disappear.

This guide focuses on Result Omissions rather than Windows Search. Everything maintains its own filename index and search settings, so rebuilding the Windows Search index will not fix an omission inside Everything. Start with the safe tests below, confirm whether omissions are responsible, and stop changing settings as soon as the missing file returns.

A controlled file search revealing a result hidden by an active omission rule.

1. Confirm the Symptom With a Small Safe Test

Before changing the index, service, exclusions, or network configuration, choose one missing file whose exact location you know. A controlled test prevents unrelated search syntax or filters from confusing the diagnosis.

1.1 Verify That You Are Using Everything 1.5

Result Omissions are an Everything 1.5 feature. Open Help > About Everything and check the displayed version. If you are using Everything 1.4, this specific feature is not the cause, and you should instead investigate filters, exclusions, indexing, permissions, and drive availability.

Everything 1.5 has been distributed separately from the stable 1.4 line, so verify the installed executable rather than assuming a shortcut launches the expected edition. Portable-app users should pay particular attention because multiple copies can retain different configurations.

Success looks like this: the About window confirms Everything 1.5, making Result Omissions a relevant possibility. If it shows 1.4, stop troubleshooting omissions and move to the index and filter checks later in this guide.

1.2 Search for One Exact Filename

Use a distinctive filename rather than a broad keyword. If necessary, create a harmless test file such as omission-check-4827.txt in a local folder that Everything normally indexes. Search for the complete filename and clear any text left from earlier searches.

  • Set the active filter to Everything.
  • Turn off Match Case, Match Path, Match Whole Word, and Match Diacritics unless required.
  • Remove regular-expression mode if it is enabled.
  • Wait briefly for the new file to enter the index.

If the known file is absent, look at the status bar. An OMIT indicator means Result Omissions are active for the current results. That is stronger evidence than a general report that Everything search is not working.

1.3 Run the Decisive Search Test

In Everything 1.5, add the following search function before the filename:

disable-result-omissions: omission-check-4827.txt

Replace the example filename with your missing item. This function disables Result Omissions for that search without requiring you to erase omission rules.

Success looks like this: the missing item appears when disable-result-omissions: is present and disappears when it is removed. At that point, you have isolated the cause. Do not rebuild the database, change the service, or alter Windows permissions. Go directly to the omission-management steps.

If the file remains absent even with omissions disabled, Result Omissions are not the only issue. Continue with filters, exclusions, and indexing checks.

2. Remove or Correct the Result Omission

An omission tells Everything to suppress selected results. It does not delete, move, or hide the underlying Windows file. Fixing the omission changes only what Everything displays.

2.1 Understand Temporary and Saved Omissions

A temporary omission applies to the current Everything session or result context. It is useful when you want to remove noisy entries while searching without creating a permanent rule. Closing or resetting the relevant state may clear a temporary omission, depending on how it was created and retained.

A saved omission is organized as a reusable rule. It can continue affecting future searches and restarts, which makes it the more likely explanation when the same files repeatedly disappear. Broad saved expressions can hide an entire directory, extension, server path, or filename pattern.

Do not assume restarting Everything permanently fixes the problem. A restart may clear a temporary omission while leaving an organized, saved omission intact.

2.2 Inspect the OMIT Indicator

When OMIT appears in the status bar, use the associated Result Omissions interface to review what is being omitted. Depending on the current Everything 1.5 build and interface configuration, you may access omission controls through the status indicator, result-list commands, or the menu used to organize Result Omissions.

Look for a rule that matches more than intended. Common mistakes include:

  • Omitting a parent folder instead of one noisy subfolder.
  • Using a wildcard that catches valid filenames.
  • Omitting an extension needed by another project.
  • Suppressing a UNC path shared by several teams.
  • Saving a temporary cleanup rule for later use.
  • Creating overlapping rules whose combined effect is unclear.

Disable one suspected omission at a time, repeat the exact-filename search, and observe the result. This preserves useful rules while identifying the specific offender.

Success looks like this: the file appears in an ordinary search without disable-result-omissions:, and the corrected rule no longer hides unrelated files. Stop changing settings once that happens.

2.3 Organize Omitted Results Instead of Deleting Every Rule

If you use omissions intentionally, organize them by purpose. Give saved omissions descriptive names that identify the scope and reason, such as a temporary build-output cleanup or a specific archive share. Avoid vague names that make later Everything troubleshooting difficult.

Prefer narrow matching criteria. For example, omit a specific generated folder under one project rather than every folder with a common name across all indexed volumes. Test each rule against both an unwanted result and a valid result before relying on it.

If you cannot immediately identify the problematic rule, disable saved omissions individually instead of removing all of them. Once the missing result returns, refine or delete only the responsible entry.

2.4 Know When to Use Exclusions Instead

Result Omissions and index exclusions solve different problems. An omission keeps an indexed item out of displayed results under the applicable omission logic. An exclusion prevents matching content from being included in the index in the first place.

Use Result Omissions when you may still need the indexed data and want flexible, reversible result control. Use an exclusion when a location should consistently remain outside the index, such as an irrelevant cache tree or an administrative location that should never be searched by that Everything instance.

Do not convert an accidental omission into a broad exclusion merely to remove the OMIT indicator. Exclusions can make diagnostics harder because disable-result-omissions: cannot reveal an item that was never indexed.

3. Check Filters, Search Options, and Index Settings

If disabling Result Omissions does not restore the file, check the other Everything settings that can produce the same visible symptom. Make one change at a time and repeat the controlled search after each change.

3.1 Reset the Current Search Context

Select the Everything filter and clear advanced matching options that are not needed. A Pictures, Audio, Executables, or custom filter can legitimately remove a valid filename from view. Match Path can also alter how a query is interpreted, while regular expressions can turn ordinary punctuation into search operators.

Try searching for a unique portion of the filename with no extra operators. Then try its full path. If the item appears after selecting the Everything filter, the index is healthy and the previous filter was responsible.

3.2 Review Index Exclusions

Open Everything Options and inspect the index exclusion settings. Check for excluded drives, folders, files, extensions, or wildcard patterns that overlap the missing item. This is particularly important if an administrator imported a configuration or if a portable copy inherited settings from another computer.

Temporarily disable only the suspected exclusion. Do not remove all security-related or operational exclusions without understanding why they exist.

Success looks like this: the known file enters the index and appears in a plain search after the relevant exclusion is corrected. Stop there. A database rebuild is unnecessary if normal updates resume.

3.3 Verify NTFS and Folder Indexing

Everything can index local NTFS volumes efficiently through filesystem metadata. Other filesystems, network shares, mapped drives, removable media, and selected directories may depend on folder indexing or other configured index sources.

In Options, confirm that the expected volume or folder is included. For a folder index, verify that the configured path still exists and that its update schedule or rescan behavior is appropriate. A disconnected mapped drive may preserve a drive letter while providing no current content to index.

For NAS paths, prefer a stable UNC path when practical because drive-letter mappings can differ by Windows account and startup context. Confirm that the account running Everything can open the same path in File Explorer.

4. Check Service, Account, Network, and Startup Context

Result Omissions are the priority when the OMIT indicator and the disabling test agree. However, account context can explain remaining missing results, especially on NAS systems and portable installations.

4.1 Confirm the Everything Service State

If your configuration uses the Everything Service, open Everything Options and verify that the client can communicate with the service. You can also inspect the service state through the Windows Services console. Restarting a stopped service is reasonable, but repeatedly reinstalling it is not the first step for an omission problem.

The service and the desktop application serve different roles. A working service does not override a result omission in the user interface, and fixing an omission does not repair a genuinely unavailable index source.

4.2 Compare Windows Account Contexts

Mapped drives are associated with user sessions and may not appear identically in elevated applications, services, scheduled tasks, or another account. If Everything starts as administrator while the drive was mapped in a standard user session, the expected mapping may be unavailable.

Launch Everything in the same ordinary account that can access the share, then test the UNC path directly. Avoid running as administrator unless the task requires it. For portable copies, confirm that the configuration and database files are writable in their current directory or configured data location.

4.3 Test Network Access Safely

Open the target share in File Explorer using the same account. If Windows requests credentials or reports that the path is unavailable, resolve that access problem before changing Everything. Check whether the NAS is online, its name resolves, and the share path has not changed.

Firewall or antivirus software can interfere with server or client connections, but do not disable protection permanently. Review logs, confirm that the correct Everything executable is allowed on the intended trusted network, and limit any server listener to the necessary interfaces. Never expose an Everything search server directly to the public internet without appropriate access controls and network design.

Layered search diagnostics checking omissions, filters, indexing, and source access in sequence.

5. Use Diagnostics Without Destroying Useful State

Diagnostics should answer a specific question: Is the item omitted, filtered, excluded, unindexed, inaccessible, or stale? Avoid destructive actions until simpler tests have ruled out those categories.

5.1 Read the Status Bar and Index Information

The status bar can reveal the result count, indexing activity, and the OMIT state. Compare the count with and without disable-result-omissions:. A higher count after disabling omissions confirms that omission logic is removing results, even if your first filename test was mistyped.

Review the relevant Options pages for indexed volumes, folders, exclusions, service settings, and server settings. Capture screenshots or notes before altering them so you can restore a working configuration.

5.2 Use Search Syntax Tests

Run progressively simpler searches:

  1. Search for the full missing filename.
  2. Search for a unique filename fragment.
  3. Repeat with disable-result-omissions:.
  4. Search for the parent folder name.
  5. Search for another known file in the same directory.

If all neighboring files appear except the target, inspect filename-specific omissions, filters, and exclusions. If the entire directory is missing, inspect the indexed source, folder index, drive availability, and path-level rules.

5.3 Review the Index Journal and Debug Output

Everything 1.5 diagnostic tools can help establish whether the application observed a filesystem change. Use the Index Journal or debug output when ordinary tests do not explain a stale index. Reproduce one action, such as creating or renaming a test file, and look for related activity rather than collecting an unbounded log.

Debug output can contain local paths, filenames, server names, and other sensitive details. Redact that information before sharing logs publicly.

5.4 Use Force Rebuild Only After Safer Checks

A Force Rebuild can help when the configured source is correct but the index remains stale or inconsistent. It is not the normal fix for Result Omissions because rebuilding an index does not necessarily remove saved omission rules.

Before rebuilding, confirm that the expected volumes and folders are selected and accessible. Record the current settings, then rebuild only if search tests indicate a genuine indexing problem. Allow indexing to finish before judging the outcome.

Success looks like this: a newly created test file and the previously missing file both appear after indexing completes. If they appear only with omissions disabled, return to the omission rules instead of rebuilding again.

6. Run a Clean Temporary Test

When several settings may have accumulated over time, a clean temporary profile can separate a configuration problem from an installation, permission, or filesystem problem. This is especially useful for portable-app users and sysadmins who manage multiple Everything configurations.

Do not overwrite or delete your normal configuration. Close the existing instance if appropriate, preserve its settings, and launch a separate Everything 1.5 test instance with a fresh temporary configuration according to the supported instance or portable workflow. Configure only the smallest local test source needed.

  1. Create a uniquely named test file in the selected location.
  2. Confirm that the clean instance indexes it.
  3. Search without custom filters or omissions.
  4. Compare the result with the normal profile.
  5. Re-enable normal settings one category at a time.

If the clean profile finds the file, Windows and the filesystem are probably functioning. The normal profile likely contains an omission, exclusion, filter, stale folder setting, or startup parameter. If both profiles fail, investigate source accessibility, filesystem support, service state, and permissions.

Also inspect shortcuts, scheduled tasks, and command-line arguments used to launch Everything. A shortcut may start a different executable, instance, configuration path, server connection, or search state than expected. Correct the launcher rather than repeatedly changing settings in the wrong instance.

7. Quick Fix Checklist

  • Confirm that Help > About identifies Everything 1.5.
  • Search for one known file with a unique name.
  • Look for the OMIT status indicator.
  • Test disable-result-omissions: filename.ext.
  • If the file returns, inspect temporary and saved Result Omissions.
  • Disable or narrow only the rule that hides valid results.
  • Use exclusions only for content that should not enter the index.
  • Set the filter to Everything and clear unnecessary search options.
  • Verify the drive, folder index, share, or server source is configured.
  • Check the service and Windows account context when relevant.
  • Use a clean temporary profile if configuration remains uncertain.
  • Force a rebuild only after confirming a genuine stale-index problem.

The most important stopping rule is simple: once the missing file appears in a normal search and a newly created test file is indexed correctly, stop changing settings. Additional changes can introduce a second problem and obscure the original cause.

8. Frequently Asked Questions

8.1 What Does OMIT Mean in Everything?

OMIT indicates that Everything 1.5 is applying Result Omissions to suppress one or more results. The underlying files have not necessarily been deleted or hidden by Windows. Test the same query with disable-result-omissions: to see whether omitted results return.

8.2 Why Does disable-result-omissions: Find My Missing File?

The function bypasses Result Omissions for that search. If the file immediately appears, the index already contains it and Everything can find it. The appropriate fix is to remove, disable, or narrow the responsible omission, not rebuild the database.

8.3 Why Did Restarting Everything Fix the Problem Only Temporarily?

A temporary omission or session state may have cleared during restart. If the issue returns, inspect organized saved omissions, startup searches, bookmarks, command-line options, and the specific configuration loaded by your shortcut. A persistent rule can be reapplied after launch.

8.4 Can an Exclusion Produce the Same Missing-Result Symptom?

Yes, but the diagnostic behavior differs. An omitted item remains indexed and can appear when Result Omissions are disabled. An excluded item is absent from the relevant index, so disable-result-omissions: will not restore it. Correct the exclusion or indexing scope and allow the source to update.

8.5 Is Everything the Same as Windows Search?

No. Everything is a separate filename-search application with its own index, filters, exclusions, services, and configuration. Windows Search settings may affect Windows Explorer or Start menu search, but rebuilding the Windows Search index does not remove an Everything Result Omission.

8.6 Why Are NAS or Mapped-Drive Results Still Missing?

The share may not be available to the account or instance running Everything, or the folder index may be stale or misconfigured. Test the UNC path in File Explorer under the same account, check the configured folder source, and verify update behavior. If disable-result-omissions: restores the NAS files, however, fix the omission first because network access and indexing are already working.


Citations

  1. Official documentation for searching and search functions in Everything 1.5. (voidtools Everything 1.5 Searching)
  2. Official Everything downloads for verifying available editions and releases. (voidtools Downloads)
  3. Official support documentation for configuring Everything options and indexes. (voidtools Everything Support)
Cindy, ContentBASE creator assistant

MEET CINDY

Your ContentBASE creator assistant

Cindy helps creators find Canva templates, content ideas, and simple ways to make better social media posts faster.

Want ready-to-use templates? Claim the free Canva bundles or browse the full bundle store.