Everything Folder Depth Search Not Working: How to Fix It

When an Everything search finds the right files but ignores the folder depth or parent boundary you intended, the problem is usually not raw search speed. It is more often a syntax issue, a path-matching interaction, an incomplete index, or a difference between the account and settings used to build the index. The safest way to fix the symptom is to test one small folder tree, verify how depth:, parents:, parent:, infolder:, and nosubfolders: behave, and only then investigate indexing, services, network shares, or portable configuration.

1. Confirm the Symptom With a Small Safe Test

Do not begin by rebuilding the database or changing several options. First, create a controlled folder tree whose expected results are easy to recognize. This separates misunderstood search syntax from a genuine indexing or configuration problem.

1.1 Create a test folder tree

Create the following folders somewhere Everything already indexes, such as an NTFS data volume:

• C:\DepthTest\Level1
• C:\DepthTest\Level1\Level2
• C:\DepthTest\Level1\Level2\Level3

Place a uniquely named file in each folder, such as depth-root-test.txt, depth-one-test.txt, depth-two-test.txt, and depth-three-test.txt. Use names that do not occur elsewhere.

Search for depth-test or another shared portion of the names. Confirm that Everything can see all the test files before adding parent or depth restrictions. If a newly created test file is absent, stop syntax testing and investigate the index first.

1.2 Establish a path-restricted baseline

Limit the search to the test tree with an explicit folder function:

parent:"C:\DepthTest"

The parent: function targets items whose immediate parent is the specified folder. It does not mean every descendant under that folder. The equivalent infolder: function follows the same immediate-parent concept:

infolder:"C:\DepthTest"

If you want to work with the complete subtree, use the folder path as a path constraint and then apply the appropriate depth rule. Quote paths containing spaces. Test the path both with and without a trailing backslash because a trailing separator can change whether Everything interprets the expression as a folder-oriented path search or as ordinary text under the current Match Path state.

1.3 Understand what the functions count

These similarly named functions answer different questions:

• parent: and infolder: constrain results to one immediate parent folder.
• nosubfolders: prevents a folder search from including deeper descendants.
• depth: filters results by folder depth.
• parents: filters according to the number of parent folders in a result path.

depth: and parents: should not automatically be treated as relative-depth controls for the folder typed immediately before them. They evaluate path structure according to Everything's search rules. If you expect them to mean “two levels below this selected folder,” validate that assumption with the controlled tree. Combining an explicit path boundary with the intended depth test is more reliable than testing against an entire drive.

Success means the unrestricted test finds every test file, while the parent or no-subfolder form returns only the expected level. Once that happens, stop changing settings. The search engine and index are functioning, and the remaining task is to adjust the production query.

2. Check Search Options and Syntax That Change Parent Matching

Everything has global search options, filters, macros, and path-matching behavior that can alter the meaning of an otherwise reasonable query. Check the active search state before assuming the database is damaged.

2.1 Check Match Path

Match Path determines whether ordinary search terms can match the full path rather than only the filename. If it is enabled, a word appearing in a parent directory can cause files below that directory to match. This can look like a depth restriction has failed even when the extra results are being admitted by another term.

Review the Search menu and note whether Match Path is active. Run the controlled query once with Match Path off and once with it on. Functions designed to operate on paths remain preferable to relying on incidental text matching.

Success means toggling Match Path produces a predictable difference, or no difference when all constraints are explicit. If turning it off removes the unexpected results, rewrite the query with parent:, infolder:, or a quoted path instead of leaving a broad path term active.

2.2 Use parent and infolder for immediate children

When you need files or folders located directly inside one directory, start with:

parent:"C:\DepthTest\Level1"

or:

infolder:"C:\DepthTest\Level1"

Add the filename term after confirming the folder constraint by itself:

parent:"C:\DepthTest\Level1" depth-one-test

If this works but a plain path expression does not, the issue is query interpretation rather than indexing. Keep the explicit function and stop troubleshooting the service or database.

2.3 Use nosubfolders for a single folder level

nosubfolders: is useful when your base search would otherwise include descendants. Apply it to a clearly specified folder search and inspect the result paths, not just the filenames. If results from Level2 or Level3 remain, simplify the query by removing filters, OR operators, macros, and unrelated terms.

A successful no-subfolder search shows items from the selected directory but none from directories below it. If it succeeds in the test tree, any failure in the real query is likely caused by another term, an active filter, or a path that does not resolve as expected.

2.4 Check quotes and trailing backslashes

Paths containing spaces should be quoted. A trailing backslash can make a search more folder-specific, but it can also lead to confusion when the closing quote, slash, or function argument is placed incorrectly. Compare carefully constructed variants rather than assuming they are identical:

• parent:"D:\Project Files"
• infolder:"D:\Project Files"
• "D:\Project Files\"

Enter these manually during testing. Text copied from web pages, scripts, or documentation may contain typographic quotation marks, escaped characters intended for another shell, or an invisible trailing space.

2.5 Clear filters, macros, and result omissions

Select the Everything filter or the broadest available filter while testing. A document, audio, executable, or custom filter can append hidden search syntax. Also clear the search box completely before entering the diagnostic query.

Check options related to omitted results and exclusions. An omitted path may make a valid parent query appear incomplete, while a custom macro can expand into additional operators. Success means the result count and paths match the test tree with no custom filter involved.

3. Verify the Index, Service, Folder Index, and Instance

Everything is not Windows Search. Windows Search uses its own indexing service and content-oriented search system. voidtools Everything maintains its own filename index, commonly using NTFS metadata for local NTFS volumes and folder indexing for locations that cannot be indexed that way. Rebuilding or troubleshooting the Windows Search index will not normally repair an Everything parent constraint.

3.1 Confirm the expected volume is indexed

Open Everything's Options pages and inspect the relevant NTFS, ReFS, or folder-indexing sections available in your installation. Confirm that the drive or folder containing the real data is included and not excluded.

For a local NTFS volume, Everything can maintain a fast metadata-based index. Network shares, mapped drives, NAS folders, removable media, and unsupported or differently handled file systems may require folder indexing. If the path is visible only through a folder index, verify that the configured root still exists and points to the intended location.

Success means a uniquely named file created in the target location appears in Everything and displays the correct full path. If it does, do not rebuild merely because a complex query is wrong.

3.2 Check whether the index is updating

Create or rename one harmless test file in the affected folder. Watch whether it appears promptly. The status bar can help confirm result counts and whether Everything is busy updating its database.

If the file never appears, check the Index Journal and the relevant indexing options. A stale index can explain missing results, but it does not usually explain why correctly indexed files ignore a parent function. Distinguishing those symptoms prevents unnecessary repairs.

3.3 Verify service and account context

Everything may use its service to access local NTFS volume metadata without requiring the desktop application to run elevated. Confirm the Everything service is installed and running if your configuration depends on it. Restarting the application or service can be a reasonable check, but repeatedly reinstalling the service will not fix malformed search syntax.

Account context matters more for folder indexes, mapped drives, and network shares. Windows services often run under a different account and may not see drive letters mapped in your interactive session. A desktop instance launched under one user can also load a different configuration from an instance launched as administrator.

Success means the same intended Everything instance can see the target path and update a test filename under the account normally used. If that succeeds, return to query testing rather than changing permissions broadly.

3.4 Check portable and multiple-instance settings

A portable copy can use a different configuration and database from an installed copy. Multiple Everything instances can also have separate indexes, search history, filters, and option files. Confirm which executable is running, where its settings are stored, and whether the window belongs to the instance you intended to test.

Also inspect startup shortcuts and command-line options. An alternate instance name, configuration location, database path, search expression, or server connection can make Everything appear to ignore a setting changed elsewhere.

Success means only the intended instance is being tested and its Options pages show the index roots you expect.

4. Check Windows, Network, and Server Conditions

Windows conditions are relevant when results are missing or a path resolves differently between sessions. They are less likely to be responsible when all files are present but a depth expression returns the wrong levels.

4.1 Test mapped drives and UNC paths

A mapped drive such as Z: may exist for your signed-in account but not for an elevated application, service account, scheduled task, or remote Everything server. Compare the mapped path with its UNC equivalent, such as \\server\share\folder, if your environment permits it.

Do not mix path forms casually inside one diagnostic test. The indexed path may be stored under a drive letter, UNC root, or server-provided namespace. Search for a unique filename first and copy the displayed parent path exactly into the parent test.

Success means the result's stored path and the path in your query use the same form.

4.2 Review permissions without broadening access unnecessarily

Folder indexing can only enumerate locations accessible under the relevant account. Verify that the account running that indexing operation can list the affected directory. Test access through File Explorer or a command prompt running under the same account context when possible.

Do not grant broad permissions merely to test Everything. Use a harmless folder you already control, or ask an administrator to verify access. If the index contains filenames but opening them fails, that is an access problem distinct from parent filtering.

4.3 Treat firewall and antivirus checks narrowly

Firewall rules matter primarily when using an Everything client-server arrangement, ETP, HTTP, or another configured network interface. They do not normally affect a local query against a healthy local database. Confirm that the intended interface is reachable only from trusted networks and that client and server settings agree.

Security software can interfere with configuration files, database updates, or network communication, but do not disable protection permanently. Review logs, restore a quarantined trusted file if appropriate, or create the narrowest vendor-approved exception after confirming the cause. Never expose an Everything search server directly to the public internet without appropriate access controls and network protections.

5. Use Diagnostics Before a Rebuild

A rebuild can fix a genuinely stale or inconsistent index, but it should follow simpler checks. It cannot correct an invalid parent expression, an active filter, a mismatched instance, or an inaccessible share.

5.1 Read the status bar and full result paths

Use the status bar to observe the result count and indexing activity. Display the Path column and sort or inspect results by path. An unexpected filename may actually be valid because one of its parent folders matches an ordinary term while Match Path is active.

Success means you can explain why every test result is included. Once the paths match the intended parent or depth boundary, stop changing settings.

5.2 Simplify the search one operator at a time

Start with a unique filename, then add constraints individually:

1. Search for the unique test-name fragment.
2. Add the explicit parent: or infolder: constraint.
3. Test nosubfolders: when only one directory level is required.
4. Add depth: or parents: only after checking their count against the test tree.
5. Add extensions, size rules, dates, filters, or OR groups last.

The first addition that changes the result unexpectedly identifies the likely source of the problem.

5.3 Capture debug information when necessary

If a minimal test behaves inconsistently, use Everything's supported debug facilities and note the exact query, active filter, Match Path state, instance, index type, and displayed result paths. Debug output is more useful when captured during one reproducible test than during a long sequence of unrelated searches.

Remove or redact sensitive filenames, server names, and user paths before sharing logs publicly.

5.4 Use Force Rebuild only for index evidence

Consider Force Rebuild when known files are absent, stale entries remain after normal updates, the Index Journal indicates a problem, or the official troubleshooting process points to index inconsistency. Close unnecessary duplicate instances first and verify the correct index roots.

Do not delete the database manually as the first step. A controlled Force Rebuild through Everything's options is safer and preserves a clearer troubleshooting path. Success means newly created, renamed, and deleted test files are reflected correctly afterward.

6. Run a Clean Temporary Test

If the controlled folder works in theory but your normal instance still behaves unpredictably, run a temporary clean test before altering production settings. Use a separate portable copy or a separate Everything instance configured according to voidtools documentation. Keep it isolated from your normal configuration and avoid pointing multiple writable instances at the same configuration or database files.

Index only the small test location when the chosen index method permits it. Leave custom filters, macros, omissions, server connections, and startup arguments out of the test. Run the same parent, no-subfolder, depth, and parents queries.

If the clean instance works, the problem is probably in the normal instance's options, filter definitions, exclusions, command-line arguments, or configuration files. Compare those areas one at a time. If the clean instance fails identically, recheck the syntax expectation against the official search documentation before changing Windows.

Stop as soon as the minimal query returns exactly the expected levels. Reintroduce one production setting at a time so the cause remains identifiable.

7. Quick Fix Checklist

• Create one small folder tree and uniquely named files.
• Confirm every test file appears without depth restrictions.
• Use parent: or infolder: for immediate children.
• Use nosubfolders: when descendants must be excluded.
• Validate depth: and parents: counts against the test tree.
• Turn Match Path off temporarily and compare results.
• Quote paths containing spaces and check trailing backslashes.
• Select the broad Everything filter and clear custom search terms.
• Inspect exclusions, omitted results, and custom macros.
• Confirm the correct volume or folder index is enabled.
• Create or rename a file to verify that the index updates.
• Check the service, account context, and mapped-drive visibility.
• Confirm you are using the intended portable or installed instance.
• Review startup shortcuts and command-line options.
• Use Force Rebuild only when evidence points to index inconsistency.

8. Frequently Asked Questions

8.1 Why does parent return fewer results than expected?

parent: is intended for items whose immediate parent is the specified folder. It does not include every deeper descendant. If you need the whole subtree, use an appropriate path constraint and then apply a carefully tested depth rule.

8.2 Are parent and infolder different?

For practical folder-boundary searches, parent: and infolder: are equivalent ways to constrain results to an immediate parent folder. If one appears to behave differently, clear the search, active filter, and macros, then compare the exact queries in the same instance.

8.3 Why does Match Path produce extra results?

With Match Path enabled, ordinary terms can match directory names in the full path. A file can therefore match even when its filename lacks the term. Use explicit path functions and inspect the Path column to identify this interaction.

8.4 Why are NAS files missing from a correct parent search?

NAS and network-share content commonly depends on folder indexing or a configured Everything server rather than local NTFS metadata indexing. Check share availability, account permissions, UNC versus mapped-drive paths, update timing, and the instance that owns the folder index.

8.5 Will rebuilding fix an incorrect depth search?

Only if the underlying index is stale or inconsistent. A rebuild will not fix misunderstood depth: or parents: behavior, Match Path interactions, active filters, malformed quotes, or a parent path stored under a different name.

8.6 When should I stop troubleshooting?

Stop when a unique test file appears promptly and the minimal parent or depth query returns exactly the expected folder levels. At that point, the index and core search behavior are working. Add the remaining production terms one at a time rather than continuing to change services, permissions, or databases.