- Find overlapping NTFS and folder indexes by comparing complete result paths.
- Remove mapped-drive, UNC, or ETP routes that index identical storage.
- Verify each fix safely before rebuilding indexes or changing Windows security.
- Confirm the Symptom With a Small Safe Test
- Check the Index Source Directly Related to the Duplicate Paths
- Check Windows Context for Network and Portable Indexes
- Use Everything’s Diagnostic Tools in a Controlled Order
- Run a Clean Temporary Test Before Changing Many Settings
- Quick Fix Checklist
- Frequently Asked Questions
Seeing the same file twice in Everything usually does not mean that Everything has found duplicate file contents. More often, the application has indexed two paths that lead to the same file. A common example is an NTFS volume indexed automatically and then added again under the Folders index. Similar duplication can occur when a network location is available through both a mapped drive and a UNC path, or when overlapping ETP server indexes are included. The safest approach is to identify the two displayed paths, remove only the redundant index source, and stop as soon as each intended path appears once.

Start with free Canva bundles
Browse the freebies page to claim ready-to-use Canva bundles, then get 25% off your first premium bundle after you sign up.
Free to claim. Canva-ready. Instant access.
1. Confirm the Symptom With a Small Safe Test
Before rebuilding an index or changing services, verify exactly what Everything is displaying. The key question is whether one physical file is being indexed through two paths or whether two real files happen to share a name.
1.1 Show the full path for both results
In Everything, use the Details view and make sure the Path or Full Path column is visible. Depending on your layout and Everything edition, you can right-click the result column header and enable the relevant path column. Search for one filename that repeatedly appears twice, then compare the complete paths.
Common duplicate-path patterns include:
D:\Projects\report.docxandD:\Projects\report.docxfrom overlapping index sourcesZ:\Team\report.docxand\\server\share\Team\report.docx- A local path and a remote ETP path representing the same storage
- Two genuinely different paths containing separate copies of the same filename
If the full paths are identical, an overlapping local index is a strong possibility. If one path uses a drive letter and the other uses a server name, the same share is probably being indexed under two names. If the paths point to different folders or volumes, confirm whether two real files exist before changing the index.
1.2 Use a harmless test file
Create a uniquely named empty text file in the affected folder, such as everything-index-test-2025.txt. Search for that exact name. Do not place sensitive information in the file, especially when testing a shared folder or remote server.
Open the properties of each result or use the full path column to compare its route. If the single test file appears under two routes, you have confirmed duplicate indexed paths. Delete the test file when finished.
Success means the cause can be described precisely, such as “the D drive is indexed as both NTFS and a folder” or “the same share appears as Z: and its UNC path.” Once you have that evidence, avoid changing unrelated filters, exclusions, or security software.
2. Check the Index Source Directly Related to the Duplicate Paths
Everything uses different indexing methods for different storage types. Local NTFS volumes can normally be indexed efficiently from NTFS metadata, while folders, network shares, and file systems that cannot use NTFS indexing may be added through folder indexing. Duplicate results arise when these sources overlap.
2.1 Remove automatically indexed NTFS drives from the Folders tab
The most common Everything duplicate results after folder index problem occurs when an NTFS volume is already indexed automatically and the same drive, or a folder inside it, is also added to the Folders list.
- Open Tools, then Options.
- Review the Indexes section and its NTFS page.
- Note which local NTFS volumes are included.
- Open the Folders page.
- Look for the same drive, such as
D:\, or a folder located on an already indexed NTFS drive. - Select the redundant Folders entry and remove it.
- Apply the change and allow Everything to update its index.
Do not remove a folder merely because it is on an NTFS volume if you deliberately excluded that volume from NTFS indexing and need folder indexing instead. The goal is to retain one intended indexing route, not to remove access to the files.
Success means the test filename appears once under its correct local path. If that happens, stop. A service restart, firewall change, or database deletion is unnecessary.
2.2 Check for overlapping folder entries
The Folders list can also contain overlapping entries. For example, indexing both D:\Archive and D:\Archive\Clients can cause the child tree to be encountered through more than one configured source, depending on the active configuration.
Keep the broad parent entry if you need the entire tree. Keep only the narrower child entry if the rest of the parent folder should not be indexed. Review exclusions after making this choice because exclusions can affect which design is practical.
After applying the change, search for files located inside and outside the former overlap. Success means intended files remain searchable and files in the overlapping area appear through only one indexed path.
2.3 Resolve mapped drive and UNC duplication
Windows can expose one network share through multiple path names. A mapped drive such as Z: may point to \\nas01\documents. If Everything indexes both, each item may appear once under the drive letter and once under the UNC path.
Choose one naming convention and use it consistently:
- Keep the UNC path when users, services, and scheduled tasks need a stable path independent of drive mappings.
- Keep the mapped drive when the drive letter is the path users consistently recognize and the mapping is reliable in that account.
- Do not index both merely for convenience if they lead to the same share.
Open the Folders options and remove the redundant mapped or UNC entry. Then wait for the folder index to update. Success means each remote file appears once, using the path format you chose.
2.4 Check ETP sources for duplicated remote paths
Everything ETP can provide remote search results from another Everything instance. Duplicates can appear when the same remote storage is indexed locally and also returned by an ETP server, or when two configured servers expose overlapping paths.
Compare the full path and any available result information carefully. Check whether:
- The client indexes a mapped share locally while an ETP server indexes the same share
- Two ETP servers index the same NAS directory
- A remote server exposes both a mapped path and its UNC equivalent
- A startup option or saved configuration reconnects to a server you no longer need
Disable or remove only the redundant source. Do not expose an ETP server directly to the public internet as a troubleshooting shortcut. Remote search should be limited to trusted networks and protected according to your organization’s security requirements.
Success means remote files remain available from the selected authoritative source and no longer appear through a second server or local folder index.
2.5 Review omissions, filters, and search syntax without confusing them with duplication
Result omissions, exclusions, and filters usually hide results rather than create duplicates. However, they can make troubleshooting confusing. Temporarily use the Everything filter and search for the exact test filename. Clear unrelated search operators and confirm that Match Case, Match Path, Match Whole Word, and regular-expression modes are in the state you expect.
A filter cannot normally repair overlapping indexes. If two rows remain with an empty or exact-name search and their paths reveal two sources, fix those sources instead of building a filter that merely conceals one row.
3. Check Windows Context for Network and Portable Indexes
Windows account context matters most when folder indexing involves mapped drives, network shares, services, or portable configurations. It is less likely to be the cause when an ordinary local NTFS volume is duplicated through both NTFS and folder indexing.
3.1 Compare the interactive user and service account
Mapped drives are associated with a user session. A drive mapped in your desktop session may not exist for a service or elevated process, while the equivalent UNC path may still be reachable. This can produce inconsistent visibility, missing results, or apparently different representations of the same share.
Check which account runs Everything and any related service. If a folder index uses a mapped drive, verify that the same account can open it. For service-oriented or multiuser setups, a UNC path is often more predictable than a per-user mapping, provided appropriate permissions are configured.
Success means Everything starts under the intended context, can access the selected network path, and returns one representation of each file.
3.2 Verify permissions before blaming the index
If Everything results are missing after you remove a redundant path, test the retained path in File Explorer under the same user context. Confirm that the account can list the folder and traverse its parents. Network share permissions and NTFS permissions can both affect access.
Do not grant broad permissions solely to make search work. Apply the least privilege required. If access is denied, correct the account or share permissions and then allow the folder index to update.
3.3 Consider file system type
Everything’s NTFS indexing applies to NTFS volumes. Removable media, NAS storage, Linux-backed shares, and volumes using other file systems commonly require folder indexing or another supported source. Do not remove a necessary Folders entry simply because the word “drive” appears in its path.
First determine whether the volume is truly included on the NTFS options page. If it is not, folder indexing may be the correct and only local method. Duplicate results on non-NTFS or network storage are more likely to come from overlapping folder paths, mapped and UNC aliases, or remote server sources.
3.4 Check firewall and antivirus only when remote access fails
A firewall or security product is unlikely to create two local results. It becomes relevant if an ETP connection fails, a network folder cannot be refreshed, or Everything search is not working across a trusted network.
Review logs and existing allow rules before changing protection. If a rule is required, limit it to the specific application, port, profile, and trusted network scope. Never disable security software permanently or publish a file-search service openly to test whether duplicate results disappear.
3.5 Review startup and portable behavior
Portable-app users may unintentionally run two Everything instances with different configurations, or launch one instance with command-line options that add a database, folder, or server source. Check Task Manager and the notification area for multiple instances. Review shortcuts, startup folders, scheduled tasks, and scripts used to launch Everything.
Also confirm which configuration file the portable copy uses. Changing Options in one instance will not fix another instance started from a different folder or profile. Success means one intended instance starts with the expected configuration and the duplicate rows no longer return after sign-in or reboot.

4. Use Everything’s Diagnostic Tools in a Controlled Order
If the duplicate source is not obvious, inspect the current configuration before forcing a rebuild. A rebuild can refresh a valid configuration, but it cannot permanently solve two sources that still overlap.
4.1 Watch the status bar and index state
After removing an index source, observe the status bar and wait for scanning or updating activity to finish. Run the exact test search again. If Everything index is not updating, confirm that the retained volume or folder is enabled and reachable.
Record the result count before and after the change. A lower count is expected when duplicate path entries are removed, but unrelated files should remain discoverable.
4.2 Use Force Rebuild only after correcting the configuration
If stale duplicate rows remain after the redundant source has been removed and normal updating has completed, use the available Force Rebuild control for the relevant index. This is safer than manually deleting the database because Everything can reconstruct the index from the settings you have already verified.
Run a rebuild only after confirming which NTFS volumes, folders, and remote sources should remain. Success means the rebuilt index contains one row for the test file and continues to include other expected files.
4.3 Use debug logging for persistent or startup-dependent duplication
Debug output is useful when duplicates return only after startup, connecting to a network, or running a shortcut. Capture the shortest reproducible sequence: start Everything, connect the drive or server, search for the unique test file, and note when the second result appears.
Look for repeated folder scans, multiple connections, unexpected command-line parameters, or a second configuration being loaded. Avoid sharing logs publicly without reviewing them because filenames, usernames, server names, and paths may be sensitive.
4.4 Inspect the Index Journal when timing matters
The Index Journal can help establish whether a path was recently added, removed, or changed. It is most useful when results become duplicated after reconnecting storage or changing an index. The journal is supporting evidence, not a substitute for comparing full paths and configured sources.
4.5 Test search syntax separately from indexing
Search for the exact unique filename with no filters. Then test a full path expression or enable path matching to isolate one route. If each route independently finds the same physical test file, the problem is source overlap. If only a broad search appears duplicated because two files share a name, the index may be functioning correctly.
5. Run a Clean Temporary Test Before Changing Many Settings
When the current profile has years of accumulated options, a temporary clean profile can distinguish a configuration problem from a storage or application problem. Back up or note the existing settings first. Do not overwrite your regular portable folder or erase its database as the first step.
- Close the regular Everything instance.
- Start a separate temporary or portable instance in a new folder, using a clean configuration.
- Ensure it does not automatically connect to existing ETP servers or load old command-line options.
- Index only one small, relevant source.
- Create and search for the unique test filename.
- Add the suspected second source and observe whether the duplicate appears.
If duplication begins immediately after adding an NTFS-backed folder that is already indexed as an NTFS volume, or after adding the UNC equivalent of a mapped drive, the cause is confirmed. Remove that source in the original profile.
If the clean profile shows one result but the normal profile shows two, compare NTFS, Folders, ETP, startup, and portable settings rather than changing Windows permissions at random. If both profiles show two different paths, investigate whether two real directory entries or copies exist.
6. Quick Fix Checklist
- Enable the full path or Path column and compare both rows.
- Create a harmless uniquely named test file in the affected folder.
- Check whether the local NTFS volume is already indexed automatically.
- Remove that drive or its overlapping child folder from the Folders tab.
- Keep either the mapped drive or UNC path for one network share, not both.
- Check whether local indexing and ETP expose the same remote storage.
- Remove overlapping ETP sources or duplicate remote path representations.
- Confirm the retained path is accessible under the account running Everything.
- Check for multiple Everything instances, portable profiles, shortcuts, or startup parameters.
- Wait for index activity to finish, then repeat the exact-name test.
- Use Force Rebuild only if corrected settings leave stale results.
- Stop changing settings as soon as one correct result remains and expected files are searchable.
7. Frequently Asked Questions
7.1 Why does Everything show the exact same file twice?
The usual reason is that two configured index sources reach the same file. A local NTFS drive may also be present in the Folders index, a mapped drive may duplicate its UNC path, or an ETP server may expose storage that is already indexed locally. Compare the full paths and remove the redundant source.
7.2 Should I remove every NTFS drive from the Folders tab?
Remove an NTFS drive or folder from the Folders tab when the same content is already included through Everything’s NTFS index and you do not have a deliberate reason for the overlap. Do not remove required folder indexes for non-NTFS storage, network shares, or volumes excluded from NTFS indexing.
7.3 Are same-name results always an indexing error?
No. Two separate files can have the same name in different directories, on different volumes, or in synchronized folders. If the full paths differ and both files exist independently, the results are expected. Everything is primarily a filename and path search tool, not a duplicate-content detector.
7.4 Why did results go missing after I removed a folder index?
You may have removed the only working source instead of a redundant one. Confirm that the volume is enabled on the appropriate index page, the retained network path is reachable, and the running account has permission to list it. Restore the folder entry if it was necessary, then reconsider which source should be authoritative.
7.5 Is Everything the same as Windows Search?
No. Everything by voidtools is a separate filename-search application with its own indexing configuration, services, folder indexes, and remote options. Windows Search has a different index and different settings. Changing Windows Search indexing locations generally will not repair overlapping sources inside Everything.
7.6 Should I delete the Everything database to fix duplicate results?
Not as a first step. First identify and remove overlapping NTFS, folder, mapped, UNC, or ETP sources. Wait for normal updating, then use the built-in Force Rebuild option if stale entries remain. Manually deleting the database without correcting the configuration can simply recreate the same duplicates.
The reliable Everything duplicate results after folder index fix is usually small: retain one authoritative path to each storage location. Once the unique test file appears once, expected files remain searchable, and the result stays correct after restarting Everything, troubleshooting is complete.