/reindex x: should also accept a deeper path

[malventano]

For manual /reindex of large network shares, it would be useful if /reindex accepted a path deeper than the root volume. Currently attempting to enter a full path deeper than x:\ results in 'index x:\abc not found'. One such example of use is where a Linux share has local files updated by a docker instance, and those changes might not be communicated to SMBD running on the server (everything is not informed of those changes if monitoring the share). The user would currently have to rescan the entire share to accomplish occasional manual updates of the index. The ability to manually trigger a rescan down a specific path would speed this up considerably, especially on larger/slower network shares.

[void]

I will consider partial matching paths with /reindex
Thank you for the suggestion.


I will also consider adding wildcard support, eg:

/reindex x:**



For now, please consider adding a bookmark:

• In Everything, from the Bookmarks menu, click Add to bookmarks....
• Change the Name to: reindex x:\abc
• Change the Search to: /reindex x:\abc
  where x:\abc is the exact path of the index.
• Click OK.

[malventano]

For now, please consider adding a bookmark:

• In Everything, from the Bookmarks menu, click Add to bookmarks....
• Change the Name to: reindex x:\abc
• Change the Search to: x:\abc
• Click OK.

Is this meant to be a workaround? Trying the above shows the current index results for x:/abc. It does not reindex that path (and I would not expect it to given what was entered into the bookmark).

[void]

*Change the Search to: /reindex x:\abc

Sorry, I forgot the /reindex part

For Everything 1.4 you will need to press ENTER from the search box after opening the bookmark.
For Everything 1.5+ you only need to open the bookmark.

[malventano]

*Change the Search to: /reindex x:\abc

Sorry, I forgot the /reindex part

Understood, but to clartfy, this would be useful once the partial matching paths change has been implemented, right? Asking because currently it returns 'index x:/abc not found'. You had me thinking this was a workaround .

[void]

'index x:/abc not found'.

Change x:\abc to the exact path of the index.
The next alpha update will support wildcards.

[malventano]

'index x:/abc not found'.

Change x:\abc to the exact path of the index.
The next alpha update will support wildcards.

Ah-ha! I believe we have been talking past each other.

The index name is 'x:'. Suggestion is to be able to reindex *a portion* of that index ('x:/abc', not the entire 'x:'). In this example, x: is a very large network share that takes minutes to reindex, but some operations on the server are modifying x:/abc in such a way that does not notify SMBD/Everything, requiring occasional manual reindexes of x: (to see recently changed files). Being able to '/reindex x:/abc' in this case would shave minutes off of the operation.

[void]

Sorry for my misunderstanding.

The next alpha update will allow you to specify a subdirectory in /rescan
Currently, Everything will only rescan entire indexes (eg: X:\).

For example, you have X: indexed and you only want to rescan X:\ABC with out rescanning the entire drive:
/rescan X:\ABC



/rescan is different to /reindex

/rescan will perform a background rescan.
You can continue to search while the background scan takes place.

/reindex marks the index as out of date and performances a reindex.
You will be unable to search until the reindex completes.



For now, use /rescan x:\

[void]

Everything 1.5.0.1316 improves the /rescan search command.

/rescan X:\abc will now rescan only X:\abc
previously you had to use /rescan X:

[malventano]

Found a related bug.
Path contains x:\abc123 and x:\abc456
User enters "/rescan x:\abc*" and presses enter.
Folders are not rescanned, and search index now contains an entry for empty folder "x:\abc*".

It appears that instead of attempting to rescan folders matching x:\abc*, a root entry for "x:\abc*" is added to the index.

If /rescan is not meant to accept *, that's fine, but then it should not add an entry to the index.
(...but it would be handy if /rescan did accept *)

Separately, for longer (partial) rescans, it would be handy if the (partial) rescan in progress was indicated in the toolbar, similarly to normal rescans.

P.S. Welcome back!

[void]

Thank you for the bug report malventano,

I am working on a fix.

I will add wildcard support to /rescan, avoid adding the folder if it doesn't exist and look into showing the progress in the status bar.

P.S. Welcome back!

Thank you.
Good to be back. Lots to do..

[void]

Everything 1.5.0.1318a fixed an issue with rescanning paths.

/rescan <path> will now only update FAT/Remote/Folder paths that exist in the index.

I have also added wildcard support.

[malventano]

Everything 1.5.0.1318a fixed an issue with rescanning paths.

Confirmed working here. Looks good!

...and look into showing the progress in the status bar.

Just making sure this one made it onto your todo list . Without any feedback, it's hard to tell when a partial /rescan has completed.

[void]

Thanks for testing.

The progress bar / displaying the current rescan path is still on my TODO list.

[void]

Everything 1.5.0.1319a adds /rescan progress to the status bar.

The path being rescanned is shown in the tooltip when hovering over the rescanning text in the status bar.

[malventano]

Everything 1.5.0.1319a adds /rescan progress to the status bar.

Awesome! Confirmed working here. Very useful to have this feedback for rescan operations!

Unsure if you're worried about this or not, but I noticed this didn't make it into the change notes. Just FYI

[malventano]

Found a possible related bug. While a /rescan was taking place, I attempted to modify the scan settings of a (different) network drive. I was not initiating any other scans - I only enabled 'Rescan on full buffer' for one of the other network drives. Upon hitting 'Apply', both the search window and the options window completely froze/hung (spinning circle) until the background /rescan completed its operation.

[void]

Thanks for testing Everything 1319 malventano,

Everything is likely "blocking" until the rescan completes.



Everything will try to wait until the database is ready and use a queue when you make changes from the options windows.
However, the /rescan works a little differently and does not flag the database as busy.

I have put this on my Things to fix list.