Everything Duplicate Search Not Working: How to Fix It

When an Everything duplicate search is not working, the cause is usually not a broken Windows Search installation. Everything by voidtools maintains its own filename index and provides duplicate-search functions based on indexed properties. Problems commonly come from using the wrong duplicate function, sorting by an unrelated property, searching an incomplete index, excluding a location, or expecting Everything to compare file contents. Start with a controlled test, confirm what Everything has indexed, and stop as soon as the expected duplicate group appears.

1. Confirm the Symptom With a Small Safe Test

Before changing services, indexes, or security settings, create a test that reveals exactly what Everything is doing. This prevents an unrelated filter, unavailable drive, or misunderstood duplicate function from sending the investigation in the wrong direction.

1.1 Create known duplicate-name files

Create two temporary folders on an indexed drive, such as C:\DuplicateTestA and C:\DuplicateTestB. In each folder, create a harmless text file named duplicate-test.txt. The contents can differ because the basic dupe: function is not a content comparison.

Open Everything, clear the search box, disable any restrictive filter, and confirm that a search for duplicate-test.txt returns both files. If only one appears, duplicate detection is not yet the main problem. Everything is missing one location or result, so investigate indexing, exclusions, result omissions, or permissions first.

If both files appear, search for:

dupe: duplicate-test.txt

Success means that both test files remain visible as a duplicate-name group. Once that happens, stop changing index settings. The duplicate function works, and the original search likely needs corrected syntax, scope, or sorting.

1.2 Test same-size files separately

To test size duplicates, create two files with exactly the same byte size, confirm that both are independently searchable, and then try:

sizedupe:

Sort the results by Size. Depending on the amount of indexed data, an unrestricted size-duplicate search can produce many results, including empty files. Narrow the test with a filename extension or path when useful:

ext:txt sizedupe:

path:C:\DuplicateTest sizedupe:

Success means that the known same-size files appear together when results are sorted by Size. This confirms size-based grouping, not identical content.

2. Understand What Dupe and Sizedupe Actually Compare

A large share of Everything duplicate search troubleshooting comes down to expectations. Everything is primarily a fast filename and indexed-property search tool. Its duplicate functions do not automatically prove that two files contain identical bytes.

2.1 Use dupe for duplicate names

The dupe: function identifies items with duplicate names. It is useful for locating repeated filenames stored in different folders, such as multiple copies of invoice.pdf or settings.json. Two files can have the same name while containing completely different data.

For a clearer review, sort by Name when using dupe:. Keeping the results sorted by the same property being evaluated places matching names together and makes the groups easier to recognize. Sorting by Date Modified or Path can scatter duplicate names across the result list and create the impression that the function failed.

Success means repeated names are adjacent and easy to inspect. If they appear correctly after sorting by Name, do not rebuild the index.

2.2 Use sizedupe for matching file sizes

The sizedupe: function identifies items sharing the same size. Sort by Size when using it. Matching size is useful for finding potential duplicates, but it is not proof of identical content. Unrelated files can contain the same number of bytes, especially when they are small or empty.

If sizedupe: returns no expected files, first search for each file normally and inspect its Size column. Confirm that both sizes are known and exactly equal. If a size is blank or stale, address indexing or property availability rather than repeatedly changing the query.

2.3 Duplicate detection covers the entire index

Everything evaluates duplicates across its entire index, not merely the visibly narrowed result set. A path, extension, or other search term controls which members are displayed, but another matching item elsewhere in the index may be what makes a visible item a duplicate.

This distinction can produce surprising results. For example, a file shown by ext:jpg dupe: may have a same-name counterpart with another extension interpretation or in a location outside the path you are reviewing, depending on the exact name and syntax involved. Search the filename without the narrow condition to inspect all indexed matches.

Use narrowing terms to make review manageable:

• ext:pdf dupe: limits displayed results to PDF files with duplicate names.
• path:D:\Archive dupe: limits displayed results to a selected path.
• ext:jpg sizedupe: shows same-size JPG candidates.
• parent:C:\Projects dupe: can help constrain results to a parent location.

Success means the broader search reveals the counterpart responsible for duplicate status. Once you understand the group, stop changing settings and refine the query instead.

3. Check Search Options, Filters, and Result Omissions

If the controlled files are individually searchable but disappear with a duplicate function, inspect the active search environment before touching the database.

3.1 Clear filters and search modifiers

Select the broadest filter, commonly Everything, and clear the search history from the active box. Filters can silently add extension, path, attribute, or other conditions. Also check whether Match Case, Match Whole Word, Match Path, regular expressions, or diacritic matching is enabled when it does not belong in the test.

Run only dupe: or sizedupe:, followed by the controlled narrow test. Avoid combining multiple unfamiliar functions during diagnosis.

Success means the files return after a filter or search option is removed. At that point, reintroduce conditions one at a time until the responsible condition is obvious.

3.2 Inspect exclusions and omitted results

Open Everything Options and review index exclusions, excluded folders, excluded files, and any result-omission features available in the installed release. An excluded path cannot contribute complete results to a duplicate search. A hidden or omitted item may still make the displayed behavior confusing, depending on how the feature and query are configured.

Do not remove all exclusions automatically. Temporarily adjust only the rule that affects the known test path, then search again. If the missing counterpart appears, rewrite the exclusion narrowly rather than abandoning useful exclusions.

3.3 Verify indexed properties and fast sorting

Duplicate functions work with indexed properties. Check the Indexes and Fast Sort options relevant to the property being tested. Name searches normally rely on Everything's core filename index, while size-based work requires reliable size information.

Interface labels can differ between Everything releases, so use the installed Options pages rather than following a screenshot from an unknown version. After changing a relevant property or fast-sort option, allow indexing to finish and repeat the small test.

Success means the status bar becomes idle and the expected group appears when sorted by Name or Size. Stop there instead of enabling every optional property.

4. Verify That Every Required Location Is Indexed

Everything cannot report a duplicate counterpart it has never indexed. This is especially important when the files span NTFS volumes, manually indexed folders, NAS shares, removable disks, or portable installations.

4.1 Check NTFS volumes and the Everything service

For supported local NTFS volumes, review the NTFS index settings and confirm that the expected volume is included. Check whether the Everything service is installed and running if your configuration depends on it. The service helps Everything access filesystem indexing information without requiring the main interface to run with elevated privileges.

Pay attention to account context. Running the interface under a different Windows account, as administrator, or through a scheduled task can load different settings or connect to a different service configuration. A portable copy launched from another folder may also use a separate configuration and database.

Success means a normal filename search finds files from every expected local volume and the indexed item count stabilizes. Only then should you retest duplicate syntax.

4.2 Review folder indexing for NAS and non-NTFS storage

Network shares, NAS folders, and file systems that are not handled through Everything's NTFS indexing mechanism generally need an appropriate folder-index configuration or another supported indexing method. Open the Folders section of Options and confirm that the exact share or local path is listed and currently reachable.

Mapped drive letters are account-specific. A share mapped as Z: in an interactive desktop session may not exist for a service, elevated process, or different user. When practical, a UNC path such as \\server\share can make the target less dependent on a drive-letter mapping, provided the relevant account has permission.

Check the folder index's update or rescan settings. A disconnected laptop, sleeping NAS, changed server name, or expired credentials can leave the index stale. Reconnect the share and run the relevant update operation rather than immediately deleting the entire Everything database.

Success means a newly created harmless test file on the share becomes searchable after the configured update. Once it does, repeat the duplicate test across the local and network locations.

4.3 Confirm portable settings and startup behavior

Portable-app users should confirm which executable and configuration file are active. Multiple Everything folders can produce separate indexes and different exclusion rules. Check the title, executable path, startup shortcut, and configuration location instead of assuming the taskbar shortcut launches the copy you just edited.

If Everything starts before a removable drive or network share is available, that location may not update as expected. Connect the storage, trigger the appropriate rescan or index update, and test a unique filename from that location.

5. Check Windows Access, Network, and Security Boundaries

Permissions do not explain every missing result, but they matter when folder indexing, network shares, or Everything server features are involved.

5.1 Test access under the same account

Using the same Windows account and elevation level that runs Everything, open the target folder and read the test file. For a share, verify that the UNC path opens without a credential prompt. If access fails, repair the share permissions, stored credentials, VPN connection, or drive mapping first.

Do not permanently disable antivirus or firewall protection. If a security product appears involved, inspect its event history and create the narrowest vendor-supported allowance for the trusted Everything executable, service, local database activity, or private network connection. Retest and retain normal protection.

5.2 Treat server options carefully

If results come through Everything's HTTP, ETP, or another server capability, compare them with a search performed directly in the local Everything interface on the machine hosting the index. Server-side restrictions, authentication, allowed search behavior, or a connection to the wrong instance can produce a different result set.

Keep file-search services restricted to trusted networks and authenticated users. Do not expose an Everything server directly to the public internet merely to troubleshoot duplicate results.

Success means the host interface and approved client return the same controlled duplicate group. If the host works but the client does not, focus on the client connection and server configuration, not the filesystem index.

6. Use Status, Rebuild, Logs, and Syntax Tests in That Order

Everything offers deeper diagnostic tools, but they should follow the safer checks. Changing several index and service settings simultaneously makes it harder to identify the actual cause.

6.1 Read the status bar first

Watch the status bar for indexing, scanning, sorting, or result-count activity. Wait for an active update to finish before judging the duplicate output. Also compare the result count for a plain filename search with the count after adding dupe:.

If a missing file cannot be found by its exact name, duplicate syntax is not the immediate issue. Return to volume, folder-index, exclusion, and access checks.

6.2 Test syntax incrementally

1. Search for the exact known filename.
2. Confirm that every expected copy appears.
3. Add dupe: and sort by Name.
4. Remove it, add sizedupe:, and sort by Size.
5. Add one extension or path restriction.
6. Remove each new condition if the result unexpectedly disappears.

This sequence distinguishes a syntax problem from an incomplete index. Command-line users should perform the same search in the graphical interface. Quoting, shell escaping, command-line flags, a different database, or connection to another Everything instance can alter command-line results.

6.3 Use Force Rebuild only when evidence supports it

A Force Rebuild is reasonable when the expected locations are configured correctly, files remain missing or stale after updates finish, and simple searches prove that the index is inconsistent. It should not be the first action because rebuilding can take time and does not correct a bad exclusion, unavailable share, wrong profile, or misunderstood duplicate function.

After a rebuild, wait until indexing completes. Success means exact-name searches return every controlled file and the matching duplicate function groups them correctly.

6.4 Capture debug information when needed

If the issue persists, use Everything's supported debugging or logging facilities to observe index updates and search behavior. Record the exact query, active filter, sort column, executable path, affected paths, filesystem type, account context, and whether the graphical interface behaves differently from a command-line or server client.

The Index Journal, where available and relevant, can help show index changes. Logs are most useful when investigating a reproducible event, such as creating a test file that never enters a folder index. Avoid publishing logs without reviewing them because paths and filenames may reveal sensitive information.

7. Run a Clean Temporary Test Before Broad Changes

If the normal profile remains confusing, use a temporary, isolated Everything configuration according to voidtools guidance. Do not overwrite the working configuration or delete the existing database. The goal is to determine whether the problem follows the data source or remains only in the customized profile.

Configure one safe local test location, create known duplicate-name and same-size files, and test the two functions with the appropriate sort columns. Do not index confidential shares merely for experimentation.

If the clean profile works, compare settings methodically: filters, exclusions, indexed volumes, folder indexes, fast sorts, result omissions, startup parameters, and server connections. If it also fails, document the exact reproducible test and consult official support resources.

8. Quick Fix Checklist

• Confirm both expected files appear in a plain exact-name search.
• Use dupe: for duplicate names and sort by Name.
• Use sizedupe: for equal sizes and sort by Size.
• Remember that neither function proves identical file content.
• Clear active filters and unnecessary match options.
• Check exclusions and result-omission settings affecting either location.
• Verify every local volume, folder, NAS share, and removable drive is indexed.
• Confirm mapped drives and UNC shares are accessible under the running account.
• Wait for folder scans or index updates to finish.
• Compare GUI, command-line, and server results against the same Everything instance.
• Use Force Rebuild only after configuration and access checks pass.
• Test with a temporary clean profile before making broad permanent changes.

9. Review Duplicate Candidates Safely

Everything can quickly identify duplicate-name or same-size candidates, but deletion requires a separate judgment. Before removing anything, compare full paths, file types, dates, sizes, ownership, and application context. Same-name files in different program folders may both be required. Same-size files may contain unrelated data.

For files that must be byte-for-byte identical, verify them with a trusted hashing or binary-comparison tool. Back up important data and prefer moving uncertain candidates to a review folder or recoverable location instead of permanently deleting them. Avoid deleting operating-system files, application components, backups, or NAS snapshots based only on dupe: or sizedupe:.

Success is not the smallest possible file count. It is a clearly understood result set in which every deletion decision is independently verified.

10. Frequently Asked Questions

10.1 Why does dupe show files that are not identical?

dupe: identifies duplicate names, not identical contents. Files with the same name can have different sizes, dates, or bytes. Use a trusted content hash or comparison tool before treating them as interchangeable.

10.2 Why does sizedupe return unrelated files?

sizedupe: groups files with equal sizes. Many unrelated files can share a size, especially zero-byte files and small generated files. Narrow by extension or path, sort by Size, and verify content separately.

10.3 Why is a file marked as a duplicate when I see only one result?

Duplicate evaluation covers the entire Everything index. A search condition may display only one member of a larger duplicate group. Remove path, extension, and filter restrictions, then search the visible item's name across the complete index.

10.4 Why are duplicates on my NAS missing?

Confirm the NAS location is configured for folder indexing, reachable under the relevant account, and recently updated. A mapped drive may exist for your desktop account but not for an elevated process or service. Test the share through its UNC path and verify a newly created safe file becomes searchable.

10.5 Is Everything the same as Windows Search?

No. Everything is a separate voidtools application with its own index, services, settings, syntax, and optional folder-index behavior. Rebuilding the Windows Search index usually does not repair an Everything duplicate-search issue. Diagnose the Everything index directly.

10.6 Should I rebuild or delete the Everything database?

Not initially. First confirm syntax, sorting, filters, exclusions, indexed locations, account access, and update status. Use Force Rebuild only when simple filename searches demonstrate a stale or inconsistent index despite correct configuration. Preserve the existing profile until a temporary clean test confirms that configuration is the problem.