Everything Properties Not Indexed: How to Fix It

When Everything displays blank property columns, returns incomplete property searches, or takes a long time to sort by size, date, attributes, or metadata, the filename index may still be working correctly. Everything always indexes file and folder names and paths. Other information can come from optional indexes, the Windows property system, or on-demand file access. The likely cause therefore depends on which property is missing, where the files are stored, and how Everything is configured.

This guide focuses on optional property indexing in voidtools Everything, not the separate Windows Search index. Begin with a small, known file and change one setting at a time. Once the expected value appears quickly and consistently, stop troubleshooting rather than rebuilding or changing unrelated options.

1. Confirm the Symptom With a Small Safe Test

First determine whether you have a filename-index problem, an optional-index problem, or a property-reading problem. These categories can look similar in the results list but require different fixes.

1.1 Test a known local file

Create or choose a small file in a local folder you can access, such as a text document in your Documents folder. Note its exact filename, approximate size, and modified date in File Explorer. Then search for the exact filename in Everything.

1. Confirm that the filename appears in Everything.
2. Display the Size and Date Modified columns if they are hidden.
3. Check whether those values appear.
4. Try sorting the small result set by Size or Date Modified.
5. Rename the test file and verify that Everything notices the change.

If the name appears immediately but a property remains blank or slow, the core name index is working. Concentrate on optional indexes, property retrieval, permissions, and storage availability. If the renamed file does not appear under its new name, investigate indexing coverage, service state, exclusions, or update monitoring first.

1.2 Identify the exact property type

Do not treat all columns as equivalent. Size, date, and file attributes are basic file-system information. Media duration, image dimensions, camera model, document author, tags, and similar metadata may depend on a Windows property handler or direct access to file contents.

A useful comparison is to test three files:

• A local text file for size and modified date.
• A local image with known dimensions or camera metadata.
• A file on the affected NAS, mapped drive, or folder index.

If basic properties work locally but metadata does not, the Windows property system or the file format may be the limitation. If local files work but network files do not, focus on account context, share availability, folder indexing, and server configuration.

1.3 Reduce the result set before judging speed

Sorting hundreds of thousands of results by a property that is not indexed can require Everything to retrieve information for many files. That can be slow even when nothing is broken, especially on a network share or sleeping disk. Add a filename, extension, folder, or path condition so the test returns only a few files.

Success means the expected property appears for a known file and sorting a small result set completes promptly. If that happens, avoid changing the database or service. The remaining delay on broad searches is probably a workload or indexing-choice issue.

2. Understand What Everything Indexes

Everything is designed primarily as a fast filename search tool. It always indexes names and paths. Depending on the version and configuration, it can also maintain optional indexes for information such as file size, dates, and attributes. When a value is not indexed, Everything may gather it on demand while displaying, searching, or sorting results.

2.1 Optional size, date, and attribute indexes

Open Everything's Options dialog and review the Indexes pages. Look for the available options related to file size, folder size, dates, attributes, or other properties required by your workflow. Labels and the exact set of choices can differ between Everything releases, so enable only options that are actually present in your installation.

An optional index is useful when you repeatedly:

• Search large collections by size or date.
• Sort broad result sets by the same property.
• Need property searches to avoid touching slow disks repeatedly.
• Query remote or folder-indexed content whose properties are expensive to retrieve.

Extra indexes consume memory and may require additional maintenance. They are not automatically the best choice for every property. Enable the smallest set that supports searches you perform frequently.

Success means the relevant column fills reliably and searches or sorts using that property become faster after the index has finished updating. Once this occurs, stop enabling additional indexes.

2.2 Properties collected on demand

If a property is not indexed, Everything may request it when needed. This can cause a blank value to appear initially and then populate later. It can also cause a sort to pause while files are opened or queried. Offline files, disconnected shares, access-denied files, and unavailable removable drives may remain blank.

Test on-demand retrieval with a narrow search. If values populate for ten local files but a broad search is slow, Everything is probably working as designed. Narrow searches, use an available optional index, or avoid sorting enormous result sets by expensive metadata.

2.3 Windows property system limitations

Some metadata is supplied through Windows property handlers rather than Everything's filename database. A handler must support the file type, the metadata must exist in the file, and the current user must be allowed to read it. A blank value does not prove that the Everything database is damaged.

Compare the same property in File Explorer's Details pane or Properties dialog. If Windows cannot show the value either, repair or install the appropriate trusted application or property handler, verify the file actually contains the metadata, or use a format that exposes the desired property. Windows Search indexing is not required for Everything's filename index, although both applications can use parts of the Windows property system for metadata.

3. Check Index Coverage and Search Controls

When results or properties are missing, verify that the affected location is included before changing performance settings. A filter, exclusion, omitted-result rule, or launch option can make a healthy index appear incomplete.

3.1 Verify NTFS and folder indexes

Everything can obtain rapid updates from supported local NTFS volumes using file-system change information. Other file systems, network shares, NAS locations, and some removable media may need folder indexing or another supported connection method.

In Options, inspect the NTFS and Folders index pages. Confirm that the affected volume or folder is included and currently available. For a mapped drive, also test its UNC path because drive mappings can differ between users and elevated processes.

Success means a newly created or renamed test file in that location appears after the expected update cycle. If names are current but only properties are slow, indexing coverage is no longer the problem.

3.2 Review exclusions and omitted results

Check the Exclude settings for excluded paths, file masks, hidden items, system items, or other rules that overlap the missing files. Also review result-list omission features if you previously hid or omitted results.

Switch temporarily to the Everything filter and clear the search box before repeating the exact-name test. A custom filter may add a path, extension, attribute, or property condition without making the restriction obvious.

Success means the known file appears with the Everything filter and an empty or exact-name search. Re-enable filters individually until the restrictive rule is identified.

3.3 Check search syntax and options

A property query can fail because of syntax rather than indexing. Test the simplest available query for the property in your installed version, using Everything's Search Help or official documentation for the exact syntax. Remove macros, regular expressions, bookmarks, and custom filters from the first test.

Also check whether options such as Match Case, Match Path, Match Whole Word, or regular-expression mode are active. These mainly affect matching, but they can make expected files disappear and create the impression that a property index is unavailable.

3.4 Inspect startup and command-line settings

Shortcuts, scheduled tasks, scripts, and portable launchers may pass command-line options that load a particular configuration, database, instance, server, or search. Start Everything directly without your wrapper and compare its behavior.

Portable users should verify that the configuration directory is writable and that they are reopening the same executable and instance. If settings revert after every launch, fix write access or the launch configuration before rebuilding anything.

4. Check the Service, Account Context, and Remote Access

The Everything service helps Everything index supported local NTFS volumes without requiring the desktop application to run as administrator. It does not automatically grant access to every network share or file property.

4.1 Verify the Everything service state

Review the service-related options in Everything and check Windows Services for the Everything service if your setup uses it. Restarting a stopped service can restore local NTFS indexing, but repeatedly reinstalling it will not fix unsupported metadata or an inaccessible NAS.

Confirm that the user interface connects to the expected service or instance. Multiple Everything installations, alpha and stable builds, or portable and installed copies can use different settings and databases.

Success means local filename changes appear promptly without running the interface as administrator. If that works, move on to property-specific tests.

4.2 Compare normal and elevated account access

A mapped drive visible in your normal desktop session may be missing from an elevated process because Windows can maintain different drive mappings by logon context. Conversely, a service account may not have the same NAS credentials as your interactive account.

Prefer a UNC path for testing, such as a server and share path, and confirm that the current Windows user can open the file in File Explorer. Do not weaken share permissions merely to make a property column populate.

4.3 Validate NAS and network-share availability

Open several affected files directly. If Windows prompts for credentials, reports that the path is unavailable, or wakes the NAS slowly, Everything cannot retrieve on-demand properties instantly. Reconnect the share with the intended account and allow any folder index to update.

If an Everything server is involved, check that the client is querying the intended server and that the server's index includes the required location and property information. Some remote query methods may expose a different set of fields than a local instance. Consult the documentation for the server method you use.

Keep servers limited to trusted networks, use firewall rules that permit only required private connections, and never expose a file-search service directly to the public internet without an appropriate secure design.

4.4 Check security software without disabling it permanently

Antivirus or endpoint protection can delay repeated metadata reads, especially when a property handler opens many files. Check the security product's logs for blocked access involving Everything or the relevant handler. Test with a small local folder and use a narrow, policy-approved exception only if the logs demonstrate interference.

Do not permanently disable protection. If no block or measurable delay appears in the logs, restore the original security configuration and continue troubleshooting elsewhere.

5. Use Everything's Diagnostic Tools Carefully

Diagnostics should answer a specific question. Use them after the small test has established whether names, basic properties, or extended metadata are affected.

5.1 Read the status bar and index information

The status bar can reveal result counts, indexing activity, sorting work, or other state information. Options and index information pages can help confirm whether a volume or folder is included and whether an update is in progress.

Wait for active indexing to finish before comparing results. A successful fix produces a stable result count, an up-to-date test filename, and the expected property value.

5.2 Use Force Rebuild only after configuration checks

A force rebuild can help when an included location remains stale despite correct service operation and update monitoring. Before using it, confirm the location is included, exclusions are correct, the disk is online, and the process has access.

Rebuilding may temporarily make results incomplete and can take time for large folder indexes. Do not delete the database as a first step. Use the application's supported rebuild control and retest one known file when the rebuild completes.

5.3 Inspect the Index Journal or debug output

If your Everything build provides an Index Journal, debug console, or logging option, use it to look for the test file's path, access errors, unavailable volumes, connection failures, or repeated property-handler errors. Enable verbose diagnostics only long enough to reproduce the problem because logs may contain sensitive filenames and paths.

A useful log identifies a concrete failure, such as access denied or a disconnected folder. If the log shows normal indexing and the property is merely requested on demand, changing the filename database is unlikely to help.

6. Run a Clean Temporary Test

When the cause remains unclear, test a clean configuration before changing many production settings. Close your normal instance, preserve its configuration, and launch a separate temporary or portable instance using a new writable folder and a distinct instance name if your version supports that feature.

1. Use a trusted Everything download appropriate for your environment.
2. Create a new temporary configuration rather than overwriting the existing one.
3. Index only a small local test folder where practical.
4. Add one optional property index needed for the test.
5. Search for a few known files and display the affected column.
6. Repeat the test on the network location only after local behavior is confirmed.

If the clean profile works, compare filters, exclusions, index choices, startup arguments, and server settings with the original profile. Do not immediately replace the working production configuration. Transfer only the setting that explains the difference.

If the clean profile has the same problem, the cause is more likely to be storage access, the Windows property handler, the file format, or a limitation of the requested property. Stop changing unrelated Everything preferences.

7. Quick Fix Checklist

• Search for one known local file by its exact name.
• Confirm that Name and Path work before investigating optional properties.
• Reduce the result set before testing property sorting speed.
• Display the affected column and identify whether it is basic or extended metadata.
• Check the available size, date, attribute, and property index options.
• Enable only the indexes used frequently on large result sets.
• Confirm the volume or folder is included in NTFS or folder indexing.
• Check exclusions, omitted results, filters, and active search modes.
• Verify that the current account can open the affected file and share.
• Use a UNC path when mapped-drive visibility differs by account context.
• Check service state, instance selection, portable write access, and launch arguments.
• Compare extended metadata with File Explorer to test the Windows property handler.
• Review status information and logs before forcing a rebuild.
• Run a clean temporary profile if configuration conflicts remain likely.

Stop when the known test file appears, the required property is populated, and repeated searches behave consistently. More changes after that point add risk without improving the confirmed result.

8. Frequently Asked Questions

8.1 Does Everything index every file property?

No. Everything always indexes names and paths. It can maintain optional indexes for certain information, including available size, date, and attribute fields. Other metadata may be obtained on demand through file access or the Windows property system. The exact options depend on the installed Everything build.

8.2 Why is a property column blank when the filename appears?

The name can come from Everything's core index while the property requires file access, an optional index, or a Windows property handler. Blank values commonly indicate unavailable metadata, insufficient permissions, an offline path, an unsupported file format, or a handler that cannot read the property.

8.3 Why does sorting by size or date take so long?

If the relevant information is not indexed, Everything may need to retrieve it for every result before completing the sort. Narrow the search first. If you frequently sort very large result sets by that field, enable the corresponding optional index when available and appropriate.

8.4 Is Everything the same as Windows Search?

No. Everything uses its own indexing and search mechanisms and is best known for rapid filename and path searching. Windows Search maintains a separate index and has different content-indexing behavior. Both may rely on Windows components for some metadata, so a broken or missing property handler can affect what either application displays without making their indexes the same.

8.5 Why are NAS properties missing while local properties work?

The share may be unavailable to the current account, the mapped drive may not exist in the elevated or service context, or on-demand metadata reads may be slow. Confirm access with a UNC path, verify credentials, inspect folder-index settings, and test only a few files before assuming the index is damaged.

8.6 Should I rebuild or delete the Everything database?

Not initially. First check index coverage, exclusions, service state, account access, search syntax, and property support. Use Force Rebuild only when the correct location remains stale after those checks. Avoid manually deleting the database unless official guidance or a diagnosed corruption issue specifically requires it.