Everything Folder Index Rescans Every Startup: How to Fix It

If an Everything folder index rescans every startup, the application may remain busy for minutes, delay results from a NAS, or repeatedly show incomplete search results. This behavior usually means that Everything cannot preserve or trust the folder index between sessions, a folder has been configured for an immediate rescan, the previous session did not save its database cleanly, or a network location was unavailable when Everything started.

This guide focuses specifically on unwanted startup rescans in voidtools Everything. Everything is not Windows Search: Windows Search builds a content-aware system index, while Everything primarily provides fast filename searches and can obtain local NTFS information from the file system. Folder indexing is commonly used for network shares, NAS folders, non-NTFS volumes, and other locations that cannot be covered in the same way. Start with a controlled test, change one setting at a time, and stop as soon as a normal restart preserves the index.

1. Confirm the Symptom With a Small Safe Test

First, make sure you are seeing a genuine folder-index rescan rather than normal database loading, NTFS index initialization, or delayed access to a network share. A large saved index can take a short time to load without scanning every folder again.

1. Open Everything and wait until its status bar indicates that indexing activity has finished.
2. Search for a distinctive filename that exists inside the affected folder index.
3. Close Everything normally through File and Exit rather than ending it in Task Manager.
4. Wait several seconds so the database and settings have time to be written.
5. Start Everything again under the same Windows account and observe the status bar.

A healthy result is that Everything loads its existing database, performs only necessary change processing, and quickly returns the test file. If it visibly traverses the entire folder tree again, continue troubleshooting. If the second launch is fast, the earlier scan may have followed an abnormal shutdown, a configuration change, or temporary network failure rather than a persistent fault.

1.1 Separate folder indexing from NTFS indexing

Open Tools, Options, Indexes, and then Folders. Confirm whether the slow location appears there. Folder indexes are separate from Everything's local NTFS volume indexes and must be maintained by rescanning or monitoring the configured folders.

If the affected path is a mapped drive, UNC share, NAS directory, FAT or exFAT volume, removable device, or another manually added folder, a folder-index configuration is likely involved. Do not troubleshoot Windows Search indexing controls because those controls do not manage the voidtools Everything database.

1.2 Record what actually happens

Note the affected path, approximate start and finish times, whether results disappear during the scan, and whether the status bar names the folder. Also record whether the problem occurs after a normal Exit, after signing out, or only after Windows shuts down. That distinction helps identify database persistence and shutdown problems.

2. Check the Folder Update and Scheduling Settings

The most direct cause of Everything scanning a folder index on startup is its folder update configuration. In Tools, Options, Indexes, Folders, select the affected folder and review every update-related control rather than assuming that its defaults fit the location.

2.1 Understand folder_update_rescan_asap

The folder_update_rescan_asap setting controls whether folder indexes that need updating are rescanned as soon as possible. When enabled, a folder considered out of date can begin rescanning immediately after Everything starts. The setting does not by itself explain why the index repeatedly becomes stale, but it can make the underlying persistence or availability problem appear as an automatic startup scan.

As a diagnostic step, disable the corresponding immediate-update behavior for the affected folder if the interface or configuration exposes it, then restart Everything normally. Do not treat this as the final solution if current results are important. The goal is to determine whether immediate rescanning is triggering the visible symptom.

Success means Everything starts without immediately traversing the folder. If results then remain stale, restore an appropriate update method and investigate why monitoring, scheduled rescans, or saved state is failing.

2.2 Review scheduled update time and interval

A scheduled rescan can coincide with login or application startup. Check the folder's scheduled update time, day, and interval. An overdue schedule may run when Everything next becomes available, which can look like a startup-only problem.

• Choose an interval appropriate to how frequently the location changes.
• Schedule large NAS or network-share rescans outside login and peak usage periods.
• Avoid unnecessarily short intervals on large, slow, or high-latency folders.
• Confirm that the configured time is not the same time Everything starts each day.

After changing the schedule, exit normally, restart once, and watch the status bar. If no rescan begins and searches still return the expected files, stop changing settings. The schedule was the likely cause.

2.3 Check change monitoring

If Everything can monitor a folder for changes, monitoring may reduce the need for repeated full rescans. However, network shares and some file systems do not provide reliable or continuous change notifications, especially while a computer is asleep, disconnected, or running under a different account.

Enable folder change monitoring only where the path and server support it reliably. Keep a sensible scheduled rescan as a safety net for network data. Success means ordinary changes appear without a full scan while periodic verification occurs at the chosen interval.

3. Verify Database and Portable Settings Persistence

Everything needs to retain its database and configuration between sessions. If its settings or database cannot be saved, every launch can resemble a first launch.

3.1 Exit normally and test database save-on-exit behavior

Let the current scan finish, then use File, Exit. Do not kill the process, terminate Windows abruptly, or immediately power off the machine. Everything normally saves its database when it exits. A forced termination can prevent the latest index state from being preserved.

Start Everything again after a short pause. If this restart is fast, but the problem returns after Windows shutdown, investigate whether Windows is ending Everything before it finishes saving. Close Everything manually before shutdown as a comparison test. Also check whether cleanup, profile-management, or application-sandbox software removes the database after logout.

Success means a completed folder index survives a normal exit and reappears immediately after relaunch. Once that works consistently, avoid deleting or rebuilding the database.

3.2 Confirm portable settings are writable

Portable Everything installations commonly store configuration near the executable, depending on how they were launched and configured. If the portable directory is read-only, inside a protected location, on removable media, or synchronized by software that restores an older copy, settings may not persist.

1. Close Everything normally.
2. Confirm your account can create and modify files in the portable folder.
3. Check whether the folder's configuration files receive a new modification time after a setting change and normal exit.
4. Avoid placing a writable portable installation under Program Files unless it is intentionally configured to store settings elsewhere.
5. Check whether security or synchronization software is rolling configuration files back.

Do not solve this by granting broad permissions to every user. Give only the account running Everything the access it needs, or move the portable installation to a user-writable location. Success means a harmless setting change remains in place after exit and restart.

3.3 Look for multiple configurations

A shortcut, scheduled task, launcher, or portable-app menu may start Everything with command-line options that select a different instance, configuration file, database location, or startup mode. You may configure one copy but later launch another.

Inspect the shortcut target, Startup folder, Task Scheduler entry, service-related launch configuration, and portable launcher. Remove obsolete duplicate startup entries rather than running several Everything instances unintentionally. Make one reversible change, restart, and verify that the same configuration and folder list are loaded.

4. Check Network Paths, Permissions, and Account Context

Large network shares are a common source of startup delays. A rescan may be expected if Everything cannot monitor the share continuously, but repeated full scans can also indicate that the path is unavailable or has different credentials at startup.

4.1 Test the share before opening Everything

Open the affected UNC path in File Explorer before launching Everything. Confirm that you can list folders and access a known file without entering credentials. If the path is unavailable, resolve name resolution, VPN, server availability, or credentials first.

Mapped drives are established per user session and may not exist for an elevated process, service, scheduled task, or different account. A drive visible as Z: in Explorer might not be visible to Everything when Everything runs under another security context. Where appropriate, configure the folder index with a stable UNC path such as \\server\share\folder instead of relying on a mapped drive letter.

Success means the same account and process context can reach the path immediately at startup. If the rescan stops after correcting the path or account context, make no further index changes.

4.2 Allow enough time for large network shares

A first scan of a large NAS can legitimately take a long time because Everything must enumerate folders across the network. Network latency, many small directories, server load, and permission checks can matter more than raw capacity.

Do not repeatedly close Everything during this initial scan. Let it complete once, exit normally, and restart. If the next launch is fast, the startup scan was expected initialization. If the entire share is enumerated again, return to persistence, scheduling, and availability checks.

4.3 Review firewall and security software safely

Host firewalls, endpoint protection, ransomware protection, or controlled-folder-access features can block configuration writes or network access. Review their logs for an explicit block involving Everything, its database location, or the file server.

Create only the narrow exception required for the trusted executable, account, folder, or private network path. Do not disable antivirus or firewall protection permanently, and do not expose an Everything HTTP, ETP, or file-search server directly to the public internet. If a server feature is not needed, leave it disabled.

Success means Everything can write its local state and access the intended private share while security controls remain active.

5. Check Exclusions, Result Omissions, and Search Options

Sometimes the index is healthy but searches appear incomplete. Before forcing another scan, rule out filters and search settings that hide results.

5.1 Run a neutral search syntax test

Clear the search box, select the Everything filter, and turn off case matching, whole-word matching, path matching, diacritics matching, and regular expressions unless they are needed. Search for a simple portion of the known filename, then search using its parent folder or full path.

If the file appears with neutral settings, indexing is working and a search option or filter caused the missing result. Reset or correct that option instead of rebuilding the index.

5.2 Inspect exclusions and omitted results

Open the exclusion settings and look for excluded paths, hidden or system exclusions, filename patterns, or filters that cover the missing location. Also check whether results have been omitted or temporarily hidden by a command or view option.

Remove only an exclusion you know is unintended. Success means the test file appears immediately without a folder rescan. That demonstrates that the database contained the item all along.

5.3 Review server and command-line options

If Everything connects to another Everything instance or server, the displayed results may come from a remote database rather than the local folder index you are troubleshooting. Confirm whether an ETP, HTTP, or other server-related option is active and which instance supplies the results.

Also inspect command-line arguments for options that force rebuilding, select an alternate configuration, suppress saving, or start a different named instance. Remove only the suspicious argument and preserve a copy of the original shortcut. A successful restart loads the expected local configuration without requesting a full folder scan.

6. Use Diagnostics Before Forcing a Rebuild

Force Rebuild is useful when the stored index is demonstrably inconsistent, but it should not be the first response to every startup scan. Rebuilding can temporarily hide the symptom without correcting the reason the database becomes unavailable again.

6.1 Watch the status bar and Options pages

The status bar helps distinguish an active folder scan from an ordinary search or database load. Compare the named path and activity with the folders configured under Indexes. Confirm that the path is not listed twice under different forms, such as both a mapped drive and its UNC equivalent.

Duplicate folder entries can produce extra work and confusing results. Remove only the redundant entry after confirming that both paths identify the same location.

6.2 Use debug logging for repeatable failures

When the problem occurs on every launch, enable Everything's supported debugging output, reproduce one clean exit and restart, and then inspect the messages around database loading, settings loading, folder availability, monitoring, and rescan initiation.

Do not publish logs without reviewing them. They can contain filenames, folder paths, server names, or account-related information. A useful log should answer a focused question: did Everything fail to load saved state, decide a folder was overdue, lose access to the path, or receive a startup option that requested new indexing?

6.3 Inspect the Index Journal when useful

The Index Journal can help show index changes and whether updates are being recorded. Use it to compare a known file creation, rename, or deletion with what Everything reports. This is especially useful when the complaint changes from repeated rescanning to Everything index not updating.

If ordinary changes are tracked and survive a restart, the index is functioning. Stop troubleshooting unless the full startup rescan still occurs.

6.4 Use Force Rebuild only when justified

Consider Force Rebuild after you have confirmed that results are genuinely inconsistent, the saved database is writable, the folder remains available, and no schedule or command-line argument explains the scan. Let the rebuild finish, exit normally, and restart once.

Success means the rebuilt index loads normally on subsequent starts. If it rescans again immediately, rebuilding was not the solution. Return to database persistence, portable permissions, account context, and startup arguments.

7. Run a Clean Temporary Test

A temporary clean profile can separate a damaged or confusing configuration from a Windows, network, or file-system problem. It is safer than deleting the working database or resetting every option at once.

1. Back up the current Everything configuration and note the existing indexed folders.
2. Start a separate temporary instance or clean portable copy in a user-writable test folder.
3. Add one small local test folder containing several harmless files.
4. Let indexing finish, close the test instance normally, and reopen it.
5. If that succeeds, repeat with a small folder on the affected share.

If the local folder survives restart but the network folder rescans, focus on share monitoring, availability, credentials, scheduling, and latency. If neither survives, focus on write permissions, launch arguments, shutdown behavior, and security controls. If both survive, compare the clean configuration with the original one instead of replacing everything blindly.

Delete the temporary test profile only after recording the result. Do not delete the production database until a backup exists and less destructive checks have failed.

8. Quick Fix Checklist

• Let one complete folder scan finish before closing Everything.
• Exit through File and Exit, then test a normal restart.
• Check immediate-rescan behavior, including folder_update_rescan_asap.
• Review each folder's scheduled update time and interval.
• Confirm the indexed path is reachable before Everything starts.
• Use a UNC path when mapped drives differ by account or elevation.
• Verify that portable settings and database files are writable and persistent.
• Inspect startup shortcuts and tasks for alternate profiles or rebuild options.
• Clear filters and exclusions before assuming Everything results are missing.
• Use the status bar and debug output to identify why a rescan starts.
• Run a small clean-profile test before changing many production settings.
• Use Force Rebuild only after safer checks indicate an inconsistent index.

After each change, let indexing settle, exit normally, and restart once. If the existing folder index loads quickly and a known file is immediately searchable, stop. Additional changes can introduce a new problem after the original one is fixed.

9. Frequently Asked Questions

9.1 When is a startup rescan expected?

A startup rescan can be expected after adding a folder, forcing a rebuild, changing relevant index settings, losing saved database state, missing a scheduled scan, or reconnecting a location that could not be monitored. It may also be normal for a network folder that requires periodic enumeration. It is not normal for the same unchanged folder to require a complete rescan after every clean exit when its database and settings are being saved correctly.

9.2 Does the Everything service prevent folder rescans?

Not necessarily. The Everything service mainly helps Everything access local NTFS volume information without running the user interface as an administrator. Manually configured folder indexes, especially NAS and network folders, have their own update, monitoring, and scheduling behavior. Check the service if local NTFS results are failing, but do not assume reinstalling it will fix a network folder's rescan schedule.

9.3 Why are Everything results missing while a share is scanning?

The folder index may still be incomplete, the share may have been unavailable, or a filter, exclusion, or alternate instance may be hiding results. Wait for the status bar to settle, clear search options, and test a known filename. Avoid repeatedly rebuilding because each rebuild can prolong the period of incomplete results.

9.4 Can I disable folder rescans completely?

You can choose more manual or less frequent updates where the available settings support them, but that creates a risk of stale results. A better fix is to identify why the folder is considered out of date, then choose reliable monitoring plus a reasonable scheduled rescan. For a rarely changing archive, manual updates may be acceptable if users understand the tradeoff.

9.5 Why does a portable copy forget my folder index?

The portable directory may not be writable, its files may be restored by a launcher or synchronization tool, or different shortcuts may load different configurations. Move the copy to a user-writable location, confirm settings survive a normal exit, and make sure every launcher targets the same instance.

9.6 What should I do if Everything search is still not working?

Test one small local folder in a clean temporary profile. If that works, add a small folder from the affected share. The comparison identifies whether the fault belongs to the original configuration, Windows permissions, or network access. Preserve logs and configuration backups before escalating the issue through official voidtools support channels.