[Suggestion] Combine /rescan and /reindex

[NotNull]

/rescan [path] is used for re-scanning non-NTFS, non-REFs volumes/folders

To rescan an NTFS volume, one would need to use /reindex [path]

Do both basically the same? Intuitively I would say /rescan re-reads basic file information (name, size, date,..) and leaves indexed content and properties as-is, whereas /reindex re-reads basic file information and content and properties ("start from scratch").

But if they indeed have the same scope: consider converging the 2 search commands (4 including aliases) into one.
Each time I need this (about once a month) I need to check the documentation which one to use for NTFS volumes.

[void]

/rescan [path]

Does a background rescan for the specified path.
Only works for FAT, folder and network drive indexes.
Doesn't work for NTFS volumes, Refs volumes, or network indexes.
The completed rescan is merged with the Everything index. (adds new files, removes deleted files and updates any modified files)
Keeps indexed properties.

The entire volume is rescanned by default.
You can specify a subfolder to speed up rescanning.
For example /rescan c:\subfolderA\subfolderB
(only c:\subfolderA\subfolderB and subfolders are rescanned)



/rescan

Does a background rescan for all FAT, folders, and network drives.
Doesn't work for NTFS volumes, Refs volumes, or network indexes.
The completed rescan is merged with the Everything index. (adds new files, removes deleted files and updates any modified files)
Keeps indexed properties.



/reindex [path]

Performs a fresh reindex of the volume.
A quick reindex is performed.
You cannot search during the quick reindex.
The quick reindex should only take a few seconds for NTFS volumes.
Indexed properties are regathered for the specified volume.
The old indexed property values persist until they are regathered in the background.



/reindex

Does a full reindex.
Same as Tools -> Options -> Indexes -> Force Rebuild
All indexed properties are regathered.
The old indexed property values persist until they are regathered in the background.

Intuitively I would say /rescan re-reads basic file information (name, size, date,..) and leaves indexed content and properties as-is, whereas /reindex re-reads basic file information and content and properties ("start from scratch").

Yes, correct.



You can now forget about /rescan and /reindex and use the simpler methods:

Tools -> Options -> Folders -> Select folder -> Rescan Now.
-or-
Tools -> Options -> NTFS -> Right click volume -> Reindex.

[therube]

Lets add (Tools | Options |-> Indexes) Force Rebuild, into the mix.
How does that play in?



what is the best (most efficient) way to reindex?
& suppose you have Properties also indexed?

say you had a (computer) glitch
& you are aware that some known files were "missed" (so are not found)

if you know the particulars, & if there were only a few files affected,
you could do something like rename the file (then revert), which would then cause said file(s) to be "found" (picked up upon)

but, if you don't know the particulars, what options are there?

reindex (all) drives (live), individually?
didn't seem particularly efficient. actual indexing was relatively quick, but then (i think it was)
sorting, & updating (in my case) [with] a lot of Windows/Tabs was not particularly efficient.

not to mention on reindex, cursor "position" & selections (focus in the Results List) is lost.

thinking it would be better, to Quit first (which would save said data),
& then run an Everything -reindex ?


Also, what are the differences between a
Indexes | Force Rebuild, &
(volume) Reindex ?

I gather Reindex will simply attempt to update, where Force Rebuild wipes the slate clean,
then goes out & indexes, plus it then re-gathers properties?

[Herkules97]

Also, what are the differences between a
Indexes | Force Rebuild, &
(volume) Reindex ?

I gather Reindex will simply attempt to update, where Force Rebuild wipes the slate clean,
then goes out & indexes, plus it then re-gathers properties?

Void said it was a quick reindex, Idk what that means but probably doesn't have to do the sorting and rebuilding stages? Or it only does it for one volume instead of the entire index. In one of the earlier stages, it has already begun reading new data so a rebuild taking place because it took too long shouldn't be an issue unless you have a HDD that has mostly small files like one HDD with 200mil files.

For the second part, it doesn't have to re-gather all properties. If force rebuild, which should be the same as one that comes after the instance has been offline for too many changes, did that then each time I messed up such as system crashed without saving more recently it'd probably take months to re-index everything for my largest instance containing all currently online devices and several offline ones.

Not sure I've ever come across missed changes on any of the instances though. Not that I would know..The closest would be the same largest instance taking its sweet time to catch up. Files that have been made haven't been missed, they just haven't been processed. It can happen if say I make 800K files and then delete those same files. Usually when I am Robocopying with /CREATE.

[therube]

*glitch

Something "glitched".
It might be my UPS, on it's last legs, perhaps? "Power" glitched, though clocks did not loose their time.
Normally, the UPS kicks in, & beeps, my monitor looses signal, the "glitch" is over, monitor comes back on, & all else is where it was, all still running.

The time before last, when this happened, my UPS kind of went into a loop, beeping, & my monitor instead of just "recovering", recovered for an instant, then lost signal, then recovered, & lost... Computer was still running, all was there, music was still playing, only things were in a state where I could not interact, so I did a hard shutdown.

On (cold) restart, all is well... except. Except a file that I knew was there, that I knew should be there, was not turning up in Everything. I thought my search string was wrong, or I was searching for the wrong item, but on manually going to the file, & opening it... it was there, just Everything was not seeing it. (At that point, I renamed it, which caused Everything to see it.)

That then brought me to "reindex".
Actually, I thought if there were a way, an efficient way to "check .db against disk" kind of search, then I could find any AWOL files, & do something to "right" them (aside from a reindex).

[void]

Update rescan and reindex definitions

Lets add (Tools | Options |-> Indexes) Force Rebuild, into the mix.
How does that play in?

Tools -> Options -> Indexes -> Force Rebuild does a full reindex.
All property indexes are regathered.

what is the best (most efficient) way to reindex?
& suppose you have Properties also indexed?

/reindex <drive:>
For example:

/reindex c:

This will just reindex the specified drive.
The indexed properties on this drive are marked as dirty and regathered.
The old indexed property values persist until they are regathered in the background

but, if you don't know the particulars, what options are there?
reindex (all) drives (live), individually?

Reindex all drives.
It's going to be the same as manually reindexing each individual drive.

thinking it would be better, to Quit first (which would save said data),
& then run an Everything -reindex ?

Having a lot of windows/tabs opened shouldn't matter.
If you think it will help, exit Everything (File -> Exit)
Delete (optionally backup first) your %LOCALAPPDATA%\Everything.db and %LOCALAPPDATA%\Everything.backup.db
Restart Everything
Everything will perform a fresh reindex.
Note: you'll lose your indexed properties with this method. They'll only show up after they have been gathered in the background.

Also, what are the differences between a
Indexes | Force Rebuild, &
(volume) Reindex ?

None.
Internally, they both force a queued rebuild.

Void said it was a quick reindex, Idk what that means but probably doesn't have to do the sorting and rebuilding stages?

A quick reindex just rebuilds a new index in memory from the old index that is already in memory.
Any volumes that are marked as out of date are reindexed from disk (if available) instead of from memory.
It's usually quick unless a volume is marked out of date and it does hit disk.
Sorting can also take some time. Having a lot of "fast sort" enabled for many properties can make this take longer.