Everything Deleted Files Still Showing: How to Fix It

When deleted files remain visible in voidtools Everything, the usual cause is a stale index rather than failed deletion. Everything may have stopped monitoring an NTFS volume, retained information from an offline folder index, lost contact with a network share, or opened a different database or configuration than the one you expected. A server or command-line client can also display results from another Everything instance. The steps below help you identify the active data source, refresh only the affected index, and confirm that the displayed file is truly gone before making broader changes.

1. Confirm the Symptom With a Small Safe Test

Start by reproducing the problem with a disposable file. This separates a current monitoring failure from a handful of old records left behind by a disconnected drive or folder index.

1. Create a uniquely named text file, such as everything-delete-test-4821.txt, in the same location where stale results have appeared.
2. Open Everything and search for the complete filename.
3. Wait until the new file appears, then delete it normally in File Explorer.
4. If you sent it to the Recycle Bin, empty the bin or delete the test file permanently from there.
5. Return to Everything, clear and re-enter the search if necessary, and observe whether the result disappears.

Everything normally updates NTFS results quickly because it can monitor file-system changes. A brief delay during startup, intensive disk activity, or journal catch-up is not automatically a fault. A result that remains after Everything has finished loading and the volume is available deserves investigation.

1.1 Distinguish a Deleted File From an Inaccessible File

Do not assume that an error opening a result proves it was deleted. The file might exist under another account, on a disconnected network path, in an unavailable encrypted location, or behind permissions that prevent your current process from opening it.

Right-click the result and inspect its full path. If available, use an option that opens the containing path. You can also copy the full path and check it in File Explorer or with Test-Path -LiteralPath 'full-path' in PowerShell. Run the check under the same Windows account that runs Everything.

• If the path exists but access is denied, this is an access or account-context issue.
• If the path points to an unavailable drive or share, the record may come from an offline index.
• If the parent location opens but the exact file does not exist, the entry is likely stale.
• If the file appears inside the Recycle Bin, it was moved rather than fully removed.

Once you establish that the exact path no longer exists, continue with index-source checks. If the file is still present, stop changing Everything settings and address the file, permissions, or storage connection instead.

2. Identify Which Index Is Supplying the Stale Result

Everything can obtain results from directly monitored NTFS volumes, manually indexed folders, removable drives, network shares, or an Everything server. The correct fix depends on which source owns the displayed path.

2.1 Check NTFS Volume Monitoring

Open Tools > Options and review the index settings for NTFS volumes. Confirm that the affected volume is listed, included in the database, and configured for monitoring where appropriate. Interface wording can vary, so focus on whether the correct drive is indexed and actively monitored.

An NTFS volume can become stale after an unexpected shutdown, service interruption, volume disconnection, or a period when Everything could not read file-system changes. Allow Everything to finish its startup work and repeat the disposable-file test.

Success means a newly created file appears and then disappears after deletion without manual intervention. At that point, stop. A working live test indicates monitoring has recovered, even if a few older records still require one refresh.

2.2 Review Folder Indexes and Rescan Intervals

Folder indexing is often used for network shares, NAS folders, non-NTFS file systems, and locations that cannot be monitored through the NTFS change journal. Unlike directly monitored NTFS volumes, these locations may depend on scheduled rescans.

In the folder index options, find the folder that contains the stale path. Verify that the path is correct, the location is currently reachable, and its rescan schedule is appropriate. If the folder has not been rescanned since deletion, initiate a rescan or wait for the configured interval.

A long rescan interval can make normal behavior look like an Everything index problem. Conversely, setting extremely frequent rescans on a large NAS can create unnecessary traffic. Choose an interval that reflects how quickly search results must reflect deletions and how expensive scanning the share is.

Success means the stale result vanishes after a completed folder rescan and a second create-delete test behaves according to the configured schedule. No additional rebuild is needed.

2.3 Look for Offline or Duplicate Folder Indexes

An offline folder index can intentionally preserve filenames while storage is unavailable. This is useful for cataloging removable disks, but it also means deleted entries may remain visible until the source reconnects and is rescanned.

Check for duplicate coverage. For example, a local NTFS volume might be indexed directly while one of its subfolders is also listed as a folder index. A share could likewise be indexed under both a mapped drive letter and a UNC path. The same logical location may then produce records maintained by different mechanisms.

Temporarily disable only the suspected duplicate folder index, or remove it from indexing if it is no longer needed. Do not delete unrelated index sources. Success means the stale duplicate disappears while valid results from the intended source remain searchable.

2.4 Check Exclusions, Result Omissions, and Filters

Exclusions usually remove content rather than preserve deleted records, but they can complicate testing. Review index exclusions, active filters, and any result-omission feature to ensure your test is visible and you are comparing the same search state before and after deletion.

Switch to the broad Everything filter, clear the search box, and then search for the unique test filename. Disable temporary search modifiers that restrict paths, dates, attributes, or file types. Also check whether a filter has a custom search expression.

If clearing the filter reveals a new test file and that result disappears when deleted, indexing is functioning. The original confusion was caused by the search view, not a stale database.

2.5 Verify Server, ETP, and Command-Line Sources

If you use an Everything server, an ETP connection, a network search setup, or the es.exe command-line interface, verify which instance answers the query. A client can show records from a remote database even while the local graphical instance is current.

Compare the same unique filename in the local Everything window and in the client or command-line query. Confirm the host, port, instance name, and account context used by scripts or shortcuts. If only the remote query is stale, troubleshoot and refresh the server-side index rather than rebuilding the local one.

Do not expose an Everything search server directly to the public internet as a troubleshooting shortcut. Keep it restricted to trusted networks and use appropriate access controls.

3. Check Windows Storage, Permissions, and Startup Context

3.1 Confirm the Everything Service State

Where the Everything Service is used, check that it is running and that the application is communicating with it. Restarting a stopped service or restarting Everything can restore monitoring after a transient failure. Use Windows Services or the relevant Everything options rather than repeatedly ending processes.

Also check whether you have multiple Everything instances running under different Windows accounts or instance names. Each instance can have separate settings and database state. A portable copy launched from a USB drive may not use the same configuration as an installed copy.

Success means you can identify one intended instance, it starts consistently, and the create-delete test updates in that instance. Stop changing startup options once that behavior is reliable.

3.2 Test Mapped Drives and Network Shares

Mapped drives are created in a user and session context. A drive mapped in your interactive desktop session might not exist for a service, scheduled task, elevated process, or another account. This can leave a folder index unable to rescan its source.

Open the mapped path from the same account and context that runs Everything. If practical, configure a folder index with the stable UNC path instead of relying on a drive letter. Confirm that the NAS is online, name resolution works, credentials are valid, and the share has not changed location.

If a network share disconnected at the time files were deleted, reconnect it and perform a folder rescan. Success means the rescan completes while the share is reachable and removes records for files that no longer exist.

3.3 Account for File-System Type

Everything's immediate NTFS indexing behavior should not be assumed for every storage type. NAS shares, FAT or exFAT removable media, virtual file systems, cloud placeholders, and other non-NTFS sources are commonly handled through folder indexing and scheduled rescans.

Check the file-system type in the drive's Windows properties. If the source is not a directly monitored local NTFS volume, evaluate its folder rescan interval and availability before treating the delay as a monitoring failure.

3.4 Consider Firewall and Antivirus Interference Carefully

Firewall rules matter mainly when a client communicates with an Everything server or when network storage must be reached. Antivirus or endpoint controls can also restrict service activity, configuration writes, or database access, but they should not be blamed without evidence.

Review security-product logs and Windows event information for a relevant block. If testing an exception is permitted by your organization, make it narrow, temporary, and limited to the trusted executable or connection. Never disable protection permanently. Success is demonstrated by a repeatable create-delete test, not merely by the absence of a warning.

4. Use Everything's Diagnostics and Repair Tools

4.1 Read the Status Bar Before Rebuilding

Inspect the Everything status bar and allow indexing, rescanning, or database loading to finish. Search for the exact filename and note the full path, volume, and whether duplicate paths appear. These details often reveal an offline drive, duplicate folder index, or remote result source.

If the stale entry disappears when the relevant rescan completes, stop there. Rebuilding a healthy database adds work without addressing an overly long rescan schedule or an unreliable share.

4.2 Use Force Rebuild When the Active Index Is Proven Stale

Force Rebuild is appropriate after you confirm that the source is available, the correct index is enabled, monitoring or rescanning should be working, and a stale entry still survives. Open Everything's index options and use the available Force Rebuild control.

A rebuild recreates the index from currently visible storage. It can temporarily increase disk activity and make results incomplete until indexing finishes. On large systems, schedule it for a suitable time. Do not start by manually deleting the database because a supported rebuild preserves a clearer and safer recovery path.

After completion, repeat the unique create-delete test. Success means the old entry is gone and the new test file is removed from results after deletion. If that happens, stop troubleshooting.

4.3 Inspect Debug Output and Index Journal Information

If the problem returns, diagnostics are more useful than repeated rebuilding. Enable Everything's documented debug output temporarily and reproduce the issue. Look for messages associated with the affected volume, failed folder scans, inaccessible paths, database loading, server connections, or change-journal processing.

Where available, review Index Journal information to determine whether Everything is recording recent additions, changes, and deletions. The Index Journal is an Everything diagnostic feature and should not be confused with the NTFS USN change journal used by Windows file systems.

Capture the time, exact path, active instance, and actions taken. Then turn off verbose diagnostics when finished so logs do not grow unnecessarily.

4.4 Run Focused Search Syntax Tests

Search for the exact test name and, when needed, restrict the query to its full folder path. Clear macros, regular-expression mode, bookmarks, and custom filters unless they are part of the issue. If a result appears twice, compare both full paths rather than relying on the filename column.

This test helps expose indexing under both a drive letter and UNC path, duplicate folder indexes, and remote versus local sources. Search syntax can narrow evidence, but it does not refresh an index by itself.

5. Run a Clean Temporary Test Before Changing Many Settings

If the source remains unclear, test with a separate temporary Everything instance or clean portable configuration. Do not overwrite your normal portable folder, database, or settings. Create a separate directory, use a distinct instance name where supported, and index only a small test location.

1. Close or clearly distinguish the normal instance to avoid querying the wrong window.
2. Start the temporary instance with its own configuration and database location.
3. Include only a small local NTFS test folder or one controlled folder-index source.
4. Create a uniquely named file and confirm it appears.
5. Delete the file and observe whether the result disappears.

If the clean instance works, Windows and the storage source are probably capable of providing current information. Compare the normal profile's index sources, duplicate folder entries, server settings, exclusions, rescan intervals, instance name, and startup arguments one category at a time.

If the clean instance also fails on a local NTFS test, concentrate on the service, volume state, permissions, and diagnostic output. If it fails only on a NAS folder, focus on reachability and rescanning. This controlled method prevents unrelated setting changes from hiding the cause.

6. Quick Fix Checklist

• Verify the exact result path and confirm the file is genuinely absent.
• Create and delete a uniquely named test file in the affected location.
• Wait for startup indexing or a current folder rescan to finish.
• Confirm the correct NTFS volume is included and monitored.
• Reconnect offline folder indexes, removable disks, mapped drives, or network shares.
• Review folder rescan intervals for NAS and non-NTFS locations.
• Remove or disable duplicate indexing through drive letters, UNC paths, or nested folders.
• Clear filters and restrictive search options during testing.
• Verify that local, server, and command-line searches target the intended instance.
• Check the Everything Service and Windows account context.
• Use Force Rebuild only after the correct source and settings are confirmed.
• Use debug output or a clean temporary profile if the problem returns.

Stop as soon as the stale result disappears and a new create-delete test updates correctly. More changes do not improve a confirmed fix and can make future diagnosis harder.

7. Frequently Asked Questions

7.1 Why Does Everything Show a File That I Already Deleted?

The entry usually belongs to an index that has not received or discovered the deletion. Common causes include interrupted NTFS monitoring, an offline folder index, a disconnected network share, a long folder rescan interval, duplicate index sources, or a query sent to a stale remote instance.

7.2 How Long Should a Deleted File Remain in Everything?

On a healthy, directly monitored local NTFS volume, deletion updates are generally expected promptly after Everything is running and caught up. Folder-indexed locations update according to their rescan behavior. A NAS deletion can therefore remain visible until the next successful scan.

7.3 Will Force Rebuild Fix Stale Deleted Entries?

It often removes stale records because Everything recreates its index from currently available sources. However, it will not permanently fix an offline share, duplicate source, unsuitable rescan interval, wrong server connection, or recurring permissions problem. Diagnose those causes first.

7.4 Should I Delete the Everything Database Manually?

Not as a first step. Confirm the active instance, source availability, monitoring, and folder rescans first. Use Everything's supported Force Rebuild option when a rebuild is justified. Manual deletion can complicate recovery and may target the wrong database when multiple or portable instances exist.

7.5 Why Are Deleted NAS Files Still Listed?

NAS content is typically indexed as a folder and refreshed by rescanning. If the share was disconnected, credentials expired, the mapped drive was unavailable to the running account, or the rescan interval has not elapsed, old entries can remain. Reconnect the share and complete a successful rescan.

7.6 Why Does the Everything Window Look Correct but a Script Shows Old Results?

The script may query a different Everything instance, database, user session, or remote server. Check its command-line arguments, instance name, host, port, startup directory, and account context. Use the same unique filename in both interfaces to prove whether they are reading the same index.