Exclude files in searches that have been fully indexed

[Herkules97]

So with my media files instance which was meant to be for music files and I've now decided to fully do all media files for because why not, I don't have an extra property, that is the properties you can index since 1.5x, that applies to all files.
I don't know if there is a way to find all files that is a part of the "Indexing properties..." list.
Before I add size on disk, just to have something that would apply to all files, is there a way to find all files that is yet to be fully indexed in a built-in sort of way? So I can skip that step..

On other dbs, the search I use to find anything it has yet to index or if there are corrupt entries that will never be indexed is "!size-on-disk:0b !size-on-disk:=>1b !folder: sort:date-accessed-descending !"\System Volume Information" max-threads:4"
But given that the media files instance contains the same files that other instances would, I'd like to avoid having to use one of those properties.

[void]

I don't know if there is a way to find all files that is a part of the "Indexing properties..." list.

There's no function to search for files which have any indexed properties.
There is a search function to find which files have a specified indexed property called is-indexed:

For example, to find files which have length indexed, include the following in your search:

is-indexed:length

You would have to do this for each property.

Before I add size on disk, just to have something that would apply to all files, is there a way to find all files that is yet to be fully indexed in a built-in sort of way? So I can skip that step..

Only for each individual property.

Use the unknown keyword with your property search.

For example, to find size-on-disk where the value is unknown, include the following in your search:

size-on-disk:unknown

Either the value has not been gathered yet, or Everything failed to gather the size on disk value.

You could then exclude these files from your property index. (I am assuming that's what you are trying to do here? -before you add the property to your index)

!size-on-disk:unknown

can be used to show files where Everything successfully gathered the property value.

[Herkules97]

I don't know if there is a way to find all files that is a part of the "Indexing properties..." list.

There's no function to search for files which have any indexed properties.
There is a search function to find which files have a specified indexed property called is-indexed:

For example, to find files which have length indexed, include the following in your search:

is-indexed:length

You would have to do this for each property.

Damn, also I want to note this is not needed it seems.
I have never used it.
If I want to find anything with size-on-disk, I just search size-on-disk:
No need for is-indexed: from what I can tell.

You could then exclude these files from your property index. (I am assuming that's what you are trying to do here? -before you add the property to your index)

Nop, not trying to exclude. It's just to see how far along it is given that there are files that have no properties.
My exclusion list was created before I started the instance, or rather inclusion list with everything else excluded. Didn't want to add a bunch of strain unnecessarily so I prepared the ini beforehand like giving every property every file type I'd like to index. I suppose if I have missed anything I can just replace all in Notepad++ to add missing filetypes as all of the properties' filetypes contain the exact same data and I don't imagine EBV tries to re-read all properties just from adding one new filetype and instead only tries to read the new filetype's properties and the rest keep the data they had before.
Anyway, I can't know if them not having a given property is because it failed to gather them or they don't have any of the properties. Size-on-disk ensures I know because ALL files will have a size(So if it's an empty column, something is brokey, zero-byte would show up as 0 not empty). So it looks like I might have to index that after all to ensure the db hasn't failed to gather extra properties as it seems to gather all extra properties if it gathers one of them. In other words if it has size-on-disk:, it probably has any other properties it would have on a successful index.

Here is some extra fluff I felt like adding in:
At least for my monolithic instance, it has failed to grab most extra properties of one device. I think it's only that device though. Something broke I guess. Some have been gathered since, when I launch a file via EBV..Maybe even from the HDD's own instance, it will update most files to have them.
So if Monolith instance has no extra properties for a file, running it via at least that instance can cause it to finally read the extra properties and maybe it might also do it if I run it from a different instance. Maybe Explorer would also cause it but I try to run everything from EBV to get run dates so I have no experience with it there.
This does not work on all files, some remain empty on those columns.
I haven't bothered asking what I can do about it in its own post, you can chime in if you want here but if it requires re-reading the entire HDD again I might just let it be for at least some months more. I do have all the properties on the HDD's own instance and I do rarely use size on disk, allocation size or whatever to de-duplicate. So have never felt like needing to fix Monolith's version of the HDD.
This probably wouldn't fix the nonsense-named files either, I think they're additional entries so if I have file C:\.txt, I have 2 entries of which one has a nonsensical name to it. I can't copy the names because that copies the normal name. These entries might be ghost entries if I already have real entries to the same file paths. And the nonsense names might be a display error from them being ghosts.
The nonsense-named files can be seen in an example of normal named and nonsense together below

Album version https://imgur.com/a/bL4h9a6

[void]

If I want to find anything with size-on-disk, I just search size-on-disk:
No need for is-indexed: from what I can tell.

size-on-disk:

will not match files with a size of 0.

!size-on-disk:unknown

will match files with any size on disk.

size-on-disk: | size-on-disk:0

will also match files with any size on disk.

At least for my monolithic instance, it has failed to grab most extra properties of one device. I think it's only that device though. Something broke I guess.

If Everything sees the device as offline, even for a second, all existing indexed property requests will be cancelled.
For Everything 1.6, I will look into internally marking items that failed to gather property values.
Everything could then retry gathering property values once the volume is back online.
I'll also look into making it easier to find items that failed to gather property values.
It can be done now, but there's noway to distinguish between "failed to gather property value" and "no property value".
For example: search for:

length:unknown

, select all items and hit Ctrl + F5.
I did want to add a property manager UI (set properties, refresh properties etc..) to Everything 1.5, but ran out of time, this might be added in Everything 1.6.

Date Run and Run Count use a different system.
Everything has its own database for these properties.

I haven't bothered asking what I can do about it in its own post, you can chime in if you want here but if it requires re-reading the entire HDD again I might just let it be for at least some months more.

As an example, search for:

e: length:unknown

where e: is your drive that failed to gather properties.
Change length: to any one of the properties you are indexing.
Select just a few items and hit Ctrl + F5.
Everything will regather all properties for the selected files.

[Herkules97]

If I want to find anything with size-on-disk, I just search size-on-disk:
No need for is-indexed: from what I can tell.

size-on-disk:

will not match files with a size of 0.

!size-on-disk:unknown

will match files with any size on disk.

size-on-disk: | size-on-disk:0

will also match files with any size on disk.

Yeah I probably shouldn't have used size on disk as an example.
The actual search I use is
!size-on-disk:0b !size-on-disk:=>1b !folder: sort:date-accessed-descending !"\System Volume Information" max-threads:4
But for example length: would find anything with length. That was the original property I used before writing that post yet I decided to be confusing and use size on disk as the example.

Date Run and Run Count use a different system.
Everything has its own database for these properties.

Yeah I know, it's just I run files via EBV to get said run counts.
If I run via Explorer obviously no such run counts are saved.
I use AJC Active Backup to store each revision..Most of the time.
With 1.4x and sometimes 1.5x when I've messed up, search history or run history might replace a revision AJC failed to gather and thus the next revision it has for a given time has +2 run counts or +2 searches for a particular respective run and search.
But for the most part I save them and then I can see each individual search and run.

Select just a few items and hit Ctrl + F5.
Everything will regather all properties for the selected files.

Yes, I've tested this with a large archive on the device that failed and it did indeed gather.
I thought F5 would do it, but when I've tried it did nothing.
However adding ctrl fixed that.
I also tried read extended info but that also never did anything.
I will get to re-reading missed data then so I can finally have that for Monolith.
I do use size-on-disk sometimes to ensure the files I see in a list aren't entirely incomplete. Like Tixati makes incomplete files taking usually 131K bytes or something like that. Being able to exclude those can be handy, but I can also exclude the entire folder it uses to get rid of all the files that way. But at least the database can be more complete now. I still lack data for 2 HDDs but those broke while EBV was gathering extra properties so I will never get size on disks for those heh.