Everything Custom Filter Not Saving: How to Fix It

You create or edit a custom filter in voidtools Everything, confirm that it works, restart the application, and discover that the filter has disappeared or reverted. This specific symptom usually indicates a settings-persistence problem, not a broken filename index. The most likely causes are an incorrect filter-organizer workflow, an unwritable portable folder, settings being stored in an unexpected Windows profile, an unclean shutdown, or an INI file being replaced by synchronization or startup automation.

The safest approach is to prove whether Everything can save one simple filter, locate the settings file it is actually using, and correct that storage problem before rebuilding indexes or changing search services. Once a test filter survives a normal restart, stop changing settings. That successful restart shows that persistence is working again.

1. Confirm the Symptom With a Small Safe Test

Begin with a controlled test that changes only the custom-filter configuration. This separates a filter-saving failure from unrelated symptoms such as missing search results, an outdated index, or an unavailable network share.

1. Open Everything normally from the shortcut you use every day.
2. Open the Filter menu and choose the option for organizing filters.
3. Create a filter with an unmistakable name, such as Persistence Test.
4. Give it a simple search expression, such as ext:txt.
5. Confirm or save the change in the filter organizer.
6. Select the new filter and verify that the results are limited to text files.
7. Exit Everything through its menu or notification-area icon rather than ending it in Task Manager.
8. Start Everything again from the same shortcut and Windows account.

Success means Persistence Test remains available and still contains the expression you entered. If it survives, custom filters are saving correctly. Stop changing persistence settings and investigate any remaining search-results problem separately.

If the filter disappears, repeat the test once while paying close attention to the organizer's confirmation buttons. Closing a dialog without confirming the edit can make a filter appear usable during the current session even though the change was not committed as expected.

1.1 Distinguish a Lost Filter From Missing Results

A saved filter is a reusable search definition. The index determines which filenames Everything knows about. These are different layers. If the filter's name is gone from the Filter menu after restarting, focus on settings storage. If the filter remains but produces incomplete results, investigate indexing, exclusions, folder indexes, search syntax, or network availability.

Everything is also distinct from Windows Search. Windows Search uses Microsoft's indexing and search components, while Everything maintains and queries its own filename index. Restarting the Windows Search service or rebuilding the Windows Search index does not normally repair a custom Everything filter that disappears after restart.

2. Check the Everything Settings Location

Everything can keep settings and data in the user's AppData profile or, in portable-style use, alongside the executable. A disappearing custom filter often means the program can use the setting in memory but cannot preserve it at the location selected for storage.

2.1 Store Settings and Data in AppData

Open Everything's Options window and inspect the general setting that controls whether settings and data are stored in the user's AppData folder. Enabling this option is usually the most reliable choice for a normally installed copy of Everything. A standard user generally has write access to the appropriate area of the user's profile, while folders under Program Files are protected.

After changing the option, exit Everything cleanly, reopen it, create the Persistence Test filter, exit again, and restart. Success means the filter survives the second launch. If it does, stop troubleshooting. Do not rebuild the database merely because the previous storage location was unwritable.

Remember that AppData is account-specific. A filter saved while Everything runs under one Windows account will not automatically appear when the interface runs under another account. This includes administrator accounts, service accounts, remote-session accounts, and alternate credentials used with Run as different user.

2.2 Find the Active INI File

Everything settings may be stored in an Everything.ini file. Depending on the selected storage mode and how the application is launched, the active INI may be in the Everything program folder or the relevant AppData location. Do not assume that the first Everything.ini found by Windows is the one currently in use.

Close Everything normally, note the modification time of likely INI files, reopen Everything, make one harmless option change, close it again, and check which file's timestamp changed. This provides practical evidence of the active settings location. Avoid editing the INI while Everything is running because the application may later overwrite manual changes with its in-memory configuration.

If no candidate file changes after a clean exit, check folder permissions, security-software events, startup parameters, and whether another process is restoring an older copy. Success means the active settings file receives a new modification time and the test filter remains after relaunch.

2.3 Check Portable Folder Write Permission

A portable copy commonly stores settings beside Everything.exe. This works only when the current user can create and modify files in that folder. Portable copies placed under Program Files, on read-only media, in a locked software-distribution directory, or on a share with restricted permissions may appear to accept changes only for the current session.

With Everything closed, try creating, renaming, and deleting an ordinary text file in the portable folder using the same Windows account. Do not weaken permissions across an entire protected directory. Instead, move the portable application to a user-writable folder or enable AppData storage where appropriate.

Success means a cleanly exited and restarted portable copy retains the test filter without requiring elevation. Avoid using Run as administrator as the permanent fix. Elevation can create a confusing split in which settings are written under a different account context or only work when the program is elevated.

3. Verify the Filter Organizer and Shutdown Workflow

Use Everything's filter organizer for lasting filter changes. Typing a search into the search box and selecting an existing filter does not automatically create a new saved filter. Likewise, changing a temporary search expression is not the same as editing the stored definition.

1. Open the filter organizer.
2. Select an existing custom filter or choose the command to create one.
3. Enter a unique name and the intended search expression.
4. Confirm the edit and close the organizer normally.
5. Reopen the organizer during the same session to verify the definition.
6. Exit Everything cleanly and test it after restart.

If the definition is already missing before Everything exits, the problem is likely the organizer workflow or invalid input rather than disk persistence. If it exists until shutdown and disappears only after relaunch, investigate the settings file and shutdown path.

3.1 Exit Everything Cleanly

Ending Everything through Task Manager, forcibly powering off Windows, terminating it through a script, or killing it during logoff can prevent pending configuration from being written. Use the application's Exit command and allow the process to close. If Everything normally remains in the notification area, closing its search window may not exit the process.

Check Task Manager after choosing Exit. When the applicable Everything user-interface process has ended, reopen it and test the filter. Success means the filter persists following a normal exit. If filters save after manual exits but disappear during shutdown or logoff, inspect shutdown scripts, kiosk controls, profile-cleanup software, and session-management tools.

3.2 Check for Multiple Copies and Startup Shortcuts

Multiple installations can make saved filters seem to vanish. For example, a desktop shortcut may launch an installed copy, while a startup task launches a portable copy with another INI. Confirm the executable path for the running user interface in Task Manager or through shortcut properties.

Inspect Startup Apps, the Startup folders, scheduled tasks, and any management scripts for duplicate Everything launches. Also check shortcut targets for command-line options that select a different instance or configuration behavior. The goal is not to remove useful administrative automation blindly. It is to ensure that your normal launches use the same executable, settings location, and Windows account.

Success means every normal launch opens the intended copy and displays the same Persistence Test filter. Once that is true, stop changing startup settings.

4. Check Windows and Environment-Specific Causes

4.1 Cloud-Synced Settings Folders

Cloud synchronization can restore an older INI, create conflict copies, delay writes, or make files temporarily unavailable. This is especially relevant when a portable Everything folder sits inside OneDrive or another synchronized workspace. It can also occur with profile-management products that synchronize parts of AppData.

Close Everything and review the synchronization client's status and conflict history. For a safe test, copy the portable application to a local, nonsynchronized, user-writable folder or switch to local AppData storage. Create the test filter and perform two clean restarts.

Success means the local test retains the filter consistently. If so, keep active settings outside the synchronized folder or adjust the approved synchronization policy. Do not resolve the issue by deleting every cloud copy until you have backed up the current settings file and identified which copy is authoritative.

4.2 Antivirus and Controlled Folder Protection

Security software can block or roll back writes to protected folders. Do not disable antivirus permanently. Instead, review Windows Security protection history, controlled-folder-access events, and equivalent logs from the installed security product around the time Everything exits.

If a block is documented, move the settings to a normal user-writable location or create a narrow allow rule in accordance with your organization's policy. Test again with one filter. Success means the INI timestamp updates and the filter survives without broadly weakening endpoint protection.

4.3 Account Context and Profile Containers

In managed environments, AppData may be redirected, reset at sign-out, or stored in a profile container. Confirm that the same user owns both sessions and that the profile is persistent. A sysadmin can compare the settings file immediately before sign-out and after sign-in to determine whether profile management restored an older version.

The Everything service, when installed, can assist the user interface with low-level indexing access. It does not mean all user-interface preferences are shared among every user. Restarting the service is therefore unlikely to repair a filter that is absent only because another account or profile is loading different settings.

4.4 Network Shares and Mapped Drives

A filter may reference a mapped drive, UNC path, or folder index on a NAS. If the filter itself remains listed but has no results, verify that the share is reachable in the same user context. Mapped drives created in one logon or elevation context may not exist in another.

Network connectivity does not usually explain why the filter definition disappears from the menu. It explains an empty or incomplete result set after the filter loads. If portable settings themselves are stored on a network share, however, share permissions, offline caching, disconnects, and file locking can directly affect saving. A local writable settings test is the fastest way to distinguish those cases.

5. Diagnose Related Search Problems Without Losing Focus

Once the custom filter survives restart, test whether it returns the intended files. Use the status bar to observe result counts and indexing state. Temporarily test the filter's expression directly in the search box. A simple expression such as ext:txt should be easier to validate than a complex combination of paths, regular expressions, macros, and exclusions.

5.1 Indexes, Exclusions, and Result Omissions

If Everything results are missing while the filter remains saved, inspect the relevant Options pages for NTFS indexes, ReFS indexes where applicable, folder indexes, and exclusions. Confirm that the target volume or folder is included and available. Check whether the search expression itself excludes the files or requires a path that has changed.

Folder indexes are particularly relevant to NAS locations and file systems that are not indexed through the same local-volume mechanisms. Confirm that the folder index has completed and that the share was reachable when it updated. Success means a known file appears with a direct filename or path search before you add the custom filter's extra conditions.

5.2 Use Force Rebuild Only for Index Symptoms

A forced rebuild can help when the index is demonstrably stale or inconsistent, but it is not a primary fix for unsaved filters. Before rebuilding, confirm that a known existing file is missing from a direct search, that the correct volume or folder is indexed, and that exclusions do not explain the omission.

If those checks point to an index problem, use Everything's supported rebuild control and allow indexing to complete. Do not delete databases manually as the first step. A rebuild is successful when known files reappear in direct searches. It does not prove that custom filters are being written to the INI, so test persistence separately.

5.3 Debug Logs and the Index Journal

Advanced users can use Everything's diagnostic or debug facilities when ordinary checks do not reveal why settings fail to write. Capture only the short period covering startup, creation of the test filter, and a clean exit. Look for configuration paths, access-denied errors, command-line behavior, or unexpected shutdowns.

The Index Journal is useful for understanding index changes, not for proving that a filter definition was saved. Use each diagnostic tool for its intended layer. This keeps troubleshooting focused and reduces unnecessary changes.

6. Run a Clean Temporary Test Before Changing More Settings

If the cause remains unclear, run a temporary clean test from a new local, user-writable folder using the appropriate official Everything package and a fresh configuration. Do not overwrite the current installation or delete its database. Back up the existing INI first while Everything is closed.

1. Create a temporary folder under your user profile.
2. Place the clean test copy there.
3. Ensure it uses a local writable settings location.
4. Do not import old settings yet.
5. Create the Persistence Test filter.
6. Exit normally and reopen the same copy twice.

If the clean profile saves the filter, the original environment has a configuration-location, permission, synchronization, startup, or profile problem. Reintroduce settings gradually rather than copying every old file at once. If the clean profile also fails, document the executable path, account, settings location, security events, and exact exit method before seeking support.

Stop as soon as the filter survives repeated clean restarts. Further changes can obscure the cause or introduce unrelated indexing problems.

7. Quick Fix Checklist

• Create one simple filter through the filter organizer and confirm the dialog.
• Exit Everything through its Exit command instead of terminating the process.
• Enable AppData settings storage for a standard installed configuration.
• For portable use, place Everything in a folder the current user can write to.
• Identify the active Everything.ini by checking modification times after a clean exit.
• Launch the same executable, shortcut, account, and configuration each time.
• Check whether cloud synchronization or profile management restores an older INI.
• Review security logs for blocked writes without permanently disabling protection.
• Investigate indexes only if the filter remains saved but expected results are missing.
• Use a clean temporary profile before rebuilding or deleting any data.

8. Frequently Asked Questions

8.1 Where Are Everything Custom Filters Stored?

Custom filters are part of Everything's settings and may be represented in the active Everything.ini configuration. The exact location depends on whether settings are stored in AppData, beside a portable executable, or under a configuration selected by the launch method. Verify the active file rather than relying on a generic path.

8.2 Why Does My Filter Work Until I Restart Everything?

The application can retain a filter in memory during the current session even when it cannot preserve the change to disk. Common causes include missing write permission, an unclean exit, another copy loading a different INI, cloud synchronization restoring an older file, or a profile that resets at sign-out.

8.3 Will Rebuilding the Everything Index Restore a Lost Filter?

Usually not. Rebuilding addresses indexed filename data. A filter that disappears from the Filter menu points to settings persistence. Rebuild only when known files are missing from direct searches after checking indexed locations and exclusions.

8.4 Does the Everything Service Save My Personal Filters?

The service and the user interface have different responsibilities. The service can support indexing access, while personal interface settings are associated with the configuration loaded by the user-facing application. Restarting the service is not a dependable fix for a filter that was never written to the active settings file.

8.5 Why Are Filter Results Empty on a NAS?

If the filter remains saved, confirm that the NAS share is reachable, the folder index is configured and current, and the path in the filter still matches. Also verify that mapped drives exist in the same account and elevation context. An unavailable NAS can cause empty results, but it normally does not erase the filter definition.

8.6 When Should I Stop Troubleshooting?

Stop changing settings when a simple custom filter survives two clean restarts from the normal shortcut and under the normal Windows account. If that filter works but a complex filter does not, troubleshoot its search syntax or indexed locations separately. This prevents a solved persistence problem from becoming an unnecessary index or service problem.