Everything Sort by Size or Date Slow: How to Fix It

Everything from voidtools can return filename results almost instantly, yet sorting those same results by Size, Date Modified, Date Created, attributes, or another property may take much longer. This usually does not mean Everything search is broken. Filename lookup and property sorting are different operations. Names can come from Everything's fast index, while a property may need to be read from the file system unless you have configured Everything to index it.

The most common causes are unindexed properties, an enormous unfiltered result set, folder-size calculation, slow network storage, incomplete folder indexes, exclusions, service or account-context differences, and portable settings that do not match an installed copy. The goal is to identify the exact slow operation, apply one relevant fix, and stop once sorting becomes acceptably fast.

1. Confirm the Symptom With a Small Safe Test

Before changing indexing options, confirm whether the delay affects searching, sorting, or both. Open Everything, search for a distinctive filename or limit the search to a small local folder, and then click the Size or Date Modified column. Do not begin with an empty search that displays every indexed object.

1.1 Compare a narrow search with an empty search

Run two controlled tests:

1. Search within a small local directory containing a few hundred or a few thousand files.
2. Repeat the sort with an empty search or a broad wildcard that returns most indexed files.

If the narrow search sorts quickly but the huge result set does not, Everything is probably functioning normally. Sorting millions of records requires more work than sorting a few hundred. This is especially noticeable when the selected property is not indexed and must be retrieved from storage.

The practical fix is to narrow before sorting. Add a path, extension, filter, size condition, or date condition first. For example, search only a project directory or limit results to a relevant file type, and then click the desired column. Success means the status bar shows a much smaller result count and the sort completes promptly. Stop changing settings if this workflow solves the problem.

1.2 Compare Name sorting with property sorting

Click the Name column and observe the response, then click Size or Date Modified. If Name sorting is fast while property sorting stalls, the issue is likely property retrieval rather than the core filename index. If every sort and every search is slow, investigate the index, service, storage, and profile state more broadly.

Also test Size and Date Modified separately. Fast date sorting with slow size sorting suggests size is not indexed or folder sizes are being calculated. Slow sorting for only one column provides a much better diagnostic clue than a general report that Everything search is not working.

2. Check the Everything Settings Directly Related to Sorting

Everything distinguishes indexed properties from unindexed properties. An indexed property is stored in Everything's database and can usually be searched and sorted without querying every matching file. An unindexed property may have to be gathered from the file system when requested. On a large result set, that difference can be dramatic.

2.1 Enable file size and date indexing when appropriate

Open Everything's Options and locate the index settings for file sizes and dates. The wording and layout can differ between Everything releases, so review the available Indexes pages rather than relying on an exact menu screenshot from another installation.

Consider enabling the relevant options when you frequently sort or search by:

• File size
• Date modified
• Date created
• Date accessed, if your workflow genuinely requires it

Index only the properties you use. Additional indexes consume memory and database space, and their initial population can take time. Date accessed also has Windows and file-system behavior considerations, so it should not be enabled merely as a speculative fix.

After enabling an index, let Everything finish updating before testing. Watch the status bar and avoid repeatedly clicking columns during the initial scan. Success means subsequent sorts of the same broad local result set become much faster. Once that improvement appears, stop. There is no benefit in enabling unrelated indexes.

2.2 Understand files versus folder sizes

A file's size is stored as file metadata and is relatively straightforward to index. A folder's apparent size is different because it may represent the sum of all files below that folder. Calculating it can require traversing many descendants. Deep trees, build directories, backup sets, and network shares can make folder-size calculation expensive.

If the slowdown occurs when folders are included, repeat the search with a files-only filter. If sorting files is fast but sorting mixed file-and-folder results is slow, folder-size retrieval is the likely bottleneck.

Enable folder-size indexing only if you regularly need folder totals and understand the indexing cost. Otherwise, exclude folders from that particular search or avoid sorting a huge mixed result set by Size. Success means a files-only search sorts quickly, or indexed folder sizes appear without a lengthy live calculation.

2.3 Review search options, filters, and result omissions

An unexpected filter can broaden or alter the search. Confirm the active filter, Match Path setting, case or whole-word options, regular-expression mode, and any result-omission settings. A filter that quietly includes folders or multiple file classes may create far more results than expected.

If Everything results are missing, check exclusions before rebuilding anything. Review excluded paths, excluded files, hidden or system-item handling, and filters. Temporarily select a broad built-in filter such as Everything for a controlled test, but preserve any exclusions that protect sensitive or irrelevant locations.

Success means the expected test file appears and the result count matches the intended scope. If results are correct and sorting is fast after correcting the filter, stop troubleshooting.

2.4 Check command-line and server-related options

If Everything is launched by a shortcut, script, scheduled task, or portable-app launcher, inspect its command-line arguments. An argument may select a different settings file, instance, database, search, server, or startup behavior. Compare the problematic shortcut with a direct launch of the intended executable.

Users connecting through an Everything server should test the same query locally on the server or host computer. If local sorting is fast but the client workflow is slow, the network connection, server configuration, result transfer, or client-side property request may be involved. Keep file-search services limited to trusted networks and authenticated or otherwise appropriately protected environments. Do not expose them directly to the public internet as a troubleshooting shortcut.

Success means the direct local instance uses the expected database and sorts quickly. At that point, correct the launcher or server path rather than changing unrelated indexing settings.

3. Check Storage, Permissions, Services, and Account Context

Everything's NTFS indexing can use the NTFS Master File Table and change journal for supported local volumes. This is different from Windows Search, which maintains its own content and property indexes. Repairing or rebuilding Windows Search is therefore unlikely to fix slow sorting inside Everything.

3.1 Verify the Everything service state

If your setup uses the Everything service, open Everything's Options and confirm that the expected service configuration is active. You can also inspect Windows Services to see whether the Everything service is running. The service helps Everything access NTFS indexing information without requiring the main interface to remain elevated.

A service problem may lead to incomplete indexing, permission prompts, or different behavior after startup. Restart the service only as a controlled test, then wait for Everything to reconnect and update. Success means the relevant local volumes appear in the index, new files are detected, and property sorting behaves consistently after restart.

3.2 Compare elevated and standard account behavior

Mapped drives and network credentials can differ between a standard process and an elevated process because Windows may provide different logon contexts. If a network folder is available in File Explorer but missing or slow in an elevated Everything instance, test Everything under the normal user account and access the share through its UNC path.

Do not run Everything as administrator solely to make sorting faster. Instead, use the service for supported local NTFS access and run the interface in the appropriate user context. Success means the same account can browse the share normally and Everything can update or read the configured folder index.

3.3 Account for file-system type

Local NTFS volumes can use Everything's specialized NTFS indexing. Other file systems, removable media, NAS storage, and ordinary network shares generally require folder indexing rather than direct NTFS journal indexing from the client. Folder indexing scans directory contents and refreshes according to its configured schedule or change-detection capabilities.

If Everything's index is not updating for a NAS folder, verify that the folder remains reachable, the saved path is valid, and the configured account has permission to list it. Confirm that a manual rescan detects a newly created test file. Success means the test file appears after the expected update cycle.

3.4 Treat network folder sorting as a storage task

Sorting a network folder by an unindexed property can generate many metadata requests. Latency, sleeping disks, VPN links, Wi-Fi instability, SMB performance, and an overloaded NAS can turn thousands of small requests into a long wait.

Use these targeted tests:

• Sort a small subfolder on the share instead of the share root.
• Compare the same operation on a local folder.
• Test by UNC path if a mapped drive behaves inconsistently.
• Confirm that the share opens promptly in File Explorer under the same account.
• Schedule folder-index updates at a sensible interval instead of forcing continuous rescans of a large, slow share.

If local sorting is fast and only a broad network sort is slow, the cause is probably remote metadata access rather than Everything's core index. Narrow the result set or index the required property where supported. Stop changing local NTFS settings because they will not accelerate a remote folder scan.

3.5 Evaluate security software without disabling protection permanently

Security software can inspect database writes, executable launches, or large bursts of file metadata access. Check its logs for blocked or heavily scanned Everything activity. If organizational policy permits, perform a brief controlled test using an approved exclusion for the trusted Everything executable or database location, then restore the original configuration if there is no measurable improvement.

Never disable antivirus or endpoint protection permanently. On managed systems, ask the administrator to review telemetry and create the narrowest safe policy exception. Success is a repeatable improvement tied to a specific approved change, not a one-time faster sort after several unrelated actions.

4. Use Everything's Diagnostic Tools Methodically

4.1 Read the status bar before interrupting the operation

The status bar can reveal the number of results and whether Everything is scanning, updating, or sorting. A massive result count explains why an empty search can be expensive. If the application is still indexing after a configuration change, let it finish before judging performance.

Record the result count and approximate sorting time for each test. This turns troubleshooting into a comparison rather than guesswork. A successful fix should reduce the delay consistently under the same query and storage conditions.

4.2 Inspect the relevant Options pages

Review the NTFS, Folders, Exclude, Indexes, Results, Service, and startup-related pages that apply to your installation. Look for duplicated folder indexes, unreachable paths, unexpectedly broad roots, disabled property indexes, or refresh schedules that repeatedly scan a large share.

Portable users should confirm where settings and the database are stored and whether that directory is writable. A launcher may copy or reset configuration files, causing Everything to lose an option after each restart. Success means the selected settings persist after closing and reopening the application.

4.3 Use Force Rebuild only after safer checks

A force rebuild can help when the database is demonstrably stale or inconsistent, but it should not be the first response to a slow property sort. Rebuilding creates work and may temporarily make performance worse while properties are repopulated.

Before rebuilding, verify the selected property index, active filter, exclusions, service, indexed volumes, folder-index paths, and result count. If new local files remain missing after ordinary update checks, or diagnostics indicate an index inconsistency, use Everything's supported Force Rebuild command and allow it to finish uninterrupted.

Success means a newly created test file appears, deleted files disappear, and indexed-property sorting improves after the rebuild completes. If sorting remains slow only on huge or remote result sets, repeated rebuilding will not solve the underlying workload.

4.4 Review the Index Journal and debug output when necessary

The Index Journal can help determine whether changes are entering the index. Create a harmless test file in an affected location, rename it, and remove it. Check whether those changes are reflected. If local NTFS changes appear but folder-index changes do not, focus on the folder index and its update schedule.

Debug logging is useful when Everything hangs on a repeatable operation, a folder scan fails, or a service connection behaves unexpectedly. Enable it only long enough to reproduce the issue, note the time, and inspect the output for the relevant path or error. Logs may contain filenames and paths, so sanitize them before sharing.

4.5 Test search syntax before blaming the index

Use a known path and filename to establish a baseline. Then add one condition at a time, such as a file-only restriction, extension, date range, or size range. A malformed regular expression or unexpectedly broad query can look like a sorting failure because it returns far more objects than intended.

Success means you can identify the specific condition that expands the result set or triggers property retrieval. Keep the corrected query and avoid making global configuration changes.

5. Run a Clean Temporary Test Before Changing Many Settings

If the cause remains unclear, test with a temporary clean Everything profile or separate instance. Preserve your existing configuration and database. Do not delete them. Follow voidtools guidance for creating a separate instance or using an alternate settings location, and make sure the test cannot overwrite your working profile.

Configure only one small local NTFS location or one small folder index. Run the same narrow search and sort by Name, Size, and Date Modified. Then enable one relevant property index and repeat.

The interpretation is straightforward:

• If the clean profile is fast, the original profile likely contains a problematic option, oversized scope, stale folder index, or launcher setting.
• If both profiles are slow on one network share, investigate that share and its metadata latency.
• If both are slow only with an empty search, reduce the result set before sorting.
• If both are slow for one unindexed property, index that property or avoid broad sorting by it.

Change one setting at a time and rerun the identical test. When a change produces a repeatable improvement and normal results remain complete, stop. Bundling service changes, exclusions, rebuilds, and antivirus changes together makes it impossible to identify the real fix.

6. Quick Fix Checklist

1. Search a small local folder and compare Name, Size, and Date Modified sorting.
2. Check the result count before sorting an empty or extremely broad search.
3. Narrow by path, extension, file type, date, or size before clicking a property column.
4. Enable file size or date indexing only for properties you use regularly.
5. Test files separately from folders to detect costly folder-size calculation.
6. Confirm the active filter, exclusions, result omissions, and search options.
7. Verify that the intended NTFS volumes or folder indexes are enabled and current.
8. Check the Everything service and run the interface in the correct account context.
9. For mapped drives, test the UNC path and confirm access under the same account.
10. For NAS results, test a small subfolder and review the folder-index update schedule.
11. Inspect shortcut, portable launcher, server, and command-line settings.
12. Use the status bar and a test file to confirm when indexing has completed.
13. Try a clean temporary profile before rebuilding or altering many settings.
14. Use Force Rebuild only when evidence points to a stale or inconsistent index.
15. Stop when results are complete and repeated sorts meet your practical performance needs.

7. Frequently Asked Questions

7.1 Why is Everything instant until I click Size?

Filename results can come directly from Everything's index. If size is not indexed, clicking Size may require metadata retrieval for every result. The delay becomes much larger with an empty search, folders that require size calculation, or network files. Enable file-size indexing when appropriate, or narrow the search before sorting.

7.2 Why is sorting by Date Modified still slow?

Date Modified may not be indexed, the index may still be populating, or the query may include a large folder index or remote share. Test a small local path first. If that is fast, the broad scope or remote storage is the likely cause. If it is slow, confirm the relevant date-index option and wait for indexing to complete.

7.3 Does rebuilding Windows Search fix Everything?

Usually not. Everything and Windows Search are separate products with different indexing systems. Everything can index local NTFS filenames from NTFS metadata and can maintain its own property and folder indexes. Troubleshoot Everything's options, service, database, volumes, and folder indexes rather than rebuilding Windows Search.

7.4 Why are Everything results missing after I changed settings?

Check the active filter, exclusions, result omissions, enabled volumes, folder-index paths, and account permissions. Also verify that the index has finished updating. Create a test file in the affected location and see whether it appears. Rebuild only if ordinary update checks fail and the index appears genuinely stale.

7.5 Can Everything sort a NAS as quickly as a local NTFS drive?

Not always. A NAS usually relies on folder indexing or remote metadata access rather than direct local NTFS journal indexing. Performance depends on network latency, share availability, the NAS disks, permissions, refresh configuration, result count, and whether the requested property is already indexed. Narrowing the query before sorting is often the most effective improvement.

7.6 Should I index every available property?

No. Index properties you frequently search or sort. Each additional index has a memory, database, and update cost. Start with file size and the specific date fields central to your workflow. Once those sorts are acceptably fast and results remain current, stop adding options.