Aborting an ongoing indexing scan

[nikov]

Hi,
Any plan for an option to abort an ongoing indexing scan? It will be extremely helpful to abort an ongoing indexing scan by pressing Esc or a button and schedule for later or next restart or next new window/tab/search.
Because sometime Everything starts re-scanning, and if that re-scanning starts at an emergency time this can be critical for the user. Due to re-scanning can sometime take a minute or more and user cannot search anything on that time.

Thank you for your consideration.

[void]

To cancel indexing:

Press Ctrl + Break.
-or-
Right click the indexing progress bar and click Cancel Indexing.

You will have to restart Everything or manually force a rebuild (Tools -> Options -> Indexes) to restart indexing.



Everything should only index once.

What is the last rebuild reason reported under Tools -> Debug -> Statistics -> Build -> Last rebuild reason?

[nikov]

Thanks, I tried `Ctrl + Break` and `Right click Cancel Indexing`.
But after indexing is canceled it shows 0 items, it does not allow you to use the old index.

If after cancel indexing, if one cannot search, then what is the use of this feature?

Also, it does not immediately cancel indexing, one still has to wait a long portion of time.

You can get the idea of the situation from the following video:

video.gif (473.64 KiB) Viewed 1624 times

`Last rebuild reason` was "Out of date NTFS volume C: is available"

I was surprised too because "C:" is the system drive. It is always running. And I probably didn't close Everything for a long time.

On another related note:
What makes Everything to consider a volume is an "Out of date NTFS volume"? Does Everything guess out of date based on system clock?
System clock can be very unstable. It is generally advised to avoid/careful use of system clock for a program's functionality.
I think Everything is careful about that.

Also, can I make an exception for "Out of date NTFS volume"? So that Everything does not automatically start re-indexing in such case?

[void]

If after cancel indexing, if one cannot search, then what is the use of this feature?

The intended use is to cancel the initial index when you first run Everything so you can manually setup your indexes.

Also, it does not immediately cancel indexing, one still has to wait a long portion of time.

Cancelling is not immediate.

Everything will finish processing the current scan.

The next alpha update will cancel immediately.

`Last rebuild reason` was "Out of date NTFS volume C: is available"

What makes Everything to consider a volume is an "Out of date NTFS volume"?

The USN Journal ID on your C: drive changed.
This means Everything doesn't know if its index is up-to-date.

This can occur if there was too many changes in a short time.

Please increase your USN Journal Size:

• In Everything 1.5, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Select your C: drive.
• Set the Maximum size to: 131072 KB
• Click OK.

Please let me know if you see Everything rebuild again.

Also, can I make an exception for "Out of date NTFS volume"? So that Everything does not automatically start re-indexing in such case?

Everything will only detect the volume as out of date if "monitor changes" is enabled.

If monitor changes is enabled, and the USN Journal ID changes, Everything will be force to perform a reindex to keep monitoring new changes.

Disabling "monitor changes" is most likely not what you want.
If you disable "monitor changes" you will need to manually reindex your C: drive to keep it up-to-date.

To disable monitor changes for your C: drive

• In Everything 1.5, from the Tools menu, click Options.
• Click the NTFS tab on the left.
• Select your C: drive.
• Uncheck Monitor changes.
• Click OK.

To manually reindex your C: drive:

• Copy and paste the following into your Everything search box:
  /reindex c:
• Press ENTER in your Everything search box.

[nikov]

Thank you for considering,
Also please note that, there is also another problem:
After canceling it shows 0 items. It would be great if it lets the user to use the old/pre-existing database/index after cancellation.

Also, now I have increased maximum USN Journal size by setting it to 131072 KB by following this.

But note that, I did not notice whether this rebuilt for "Out of date NTFS volume C: is available" happens frequently. I just noticed this for the first time. Maybe this happens very rarely.
Till now, after increasing maximum USN Journal size, this rebuilt not happened.

[Thy Grand Voidinesss]

To cancel indexing:

Press Ctrl + Break.
-or-
Right click the indexing progress bar and click Cancel Indexing.
[...]

[...]
After canceling it shows 0 items. It would be great if it lets the user to use the old/pre-existing database/index after cancellation
[...]

+1

[void]

After canceling it shows 0 items. It would be great if it lets the user to use the old/pre-existing database/index after cancellation

I will consider an option to do this.

Thank you for the suggestion.

[nikov]

Thank you for consideration.

[nikov]

Thank you for the fix,
I just tested the latest alpha (1.5.0.1360a), it immediately cancels indexing.
But I was also expecting, after cancelling it will use the old database instead of just showing 0 items.
Is it still not possible to use the old database just after cancelling?
I was very much waiting for this feature.
Thanks.

[void]

Cancelling the index in Everything 1.5.0.1360a is now instant.

But I was also expecting, after cancelling it will use the old database instead of just showing 0 items.

A lot of memory would be required.

I am considering an option to do this.

[nikov]

Thanks,
For now, I think even any slow process, something like loading the ".db" file from the hard-disk can be great too instead of just showing 0 items.
There are two ".db" files (non-backup + backup) remain. I thought Everything loads one of these ".db" files into memory when it is restarted and thus even if the active database is erased from the memory those ".db" files can come to rescue.
This was my understanding. Maybe I can be wrong.