Bookmarks search results are not being remembered

[Thy Grand Voidinesss]

I have a highly-resource-demanding Bookmarks like for example

Bookmarks > Organize Bookmarks... > Search > Custom > audio-track-count:1

which singles out files that happen to be of mono audio kind. And every time I close and re-open Everything [even without closing its Service in-between] the whole task of precise search is redone when I choose to use again that very same Bookmark


Is this intended behavior - or is my database not registering those searches for later usage and thus I am experiencing a bug?


Everything 1.5.0.1372a x64 Portable on Windows 10 Enterprise 20H2 x64 [10.0.19042]

[horst.epp]

I have a highly-resource-demanding Bookmarks like for example

Bookmarks > Organize Bookmarks... > Search > Custom > audio-track-count:1

which singles out files that happen to be of mono audio kind. And every time I close and re-open Everything [even without closing its Service in-between] the whole task of precise search is redone when I choose to use again that very same Bookmark


Is this intended behavior - or is my database not registering those searches for later usage and thus I am experiencing a bug?


Everything 1.5.0.1372a x64 Portable on Windows 10 Enterprise 20H2 x64 [10.0.19042]

To my knowledge, there was never being a cache of search results when you close a Window.
You may store results into efu files or not close Windows for later opening the same results.
______________________________________________________
Windows 11 Home x64 Version 23H2 (OS Build 22631.3527)
Everything 1.5.0.1375a (x64), Everything Toolbar 1.3.3

[void]

Is this intended behavior - or is my database not registering those searches for later usage and thus I am experiencing a bug?

The values for the audio-track-count property are stored in Everything cache.
This cache is cleared when you close your Everything Search window.

Consider enabling Tools -> Options -> Advanced -> Hide on close.
When enabled, the closed window is instead hidden and restored when you show a new window.
The property cache is not cleared when a window is hidden.

Consider indexing this information under Tools -> Options -> Properties.

[Thy Grand Voidinesss]

The values for the audio-track-count property are stored in Everything cache.
[...]
This cache is cleared when you close your Everything Search window.
[...]
The property cache is not cleared when a window is hidden.

What constitutes as this closing you speak of? Disappearance of Everything from the Taskbar [but remaining in the Tray area]- or closing of the program's EXE [with exception of Everything Service]?

Consider indexing this information under Tools -> Options -> Properties.

So if I have more such Bookmarks, e.g.

Code: Select all

video-track-count:<1  

then if I wish to be able to use them efficiently [i.e. instantly] I should index "them" all by adding their expression at

Tools > Options > Indexes > Properties > ...

where exactly? In which box?

[void]

What constitutes as this closing you speak of?

Closing the window.

Hide on close

if I wish to be able to use them efficiently [i.e. instantly] I should index "them" all by adding their expression at

To index video track count:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Properties tab on the left.
• Click Add....
• Search for: track
• Select Video Track Count and click OK.
  (repeat for additional properties)
• Click OK.

Indexing Properties

[Thy Grand Voidinesss]

So choosing

Tools > Options > Advanced > hide_on_close > true

helps during a session for repeated searches by simply storing their results. [In my humble opinion this option should be turned on by default] But if user closes Everything's EXE then the search results are lost for good [and thus choosing a demanding Bookmark will once gain take time to execute a search process coming out of it] - and if I understood correctly, to mitigate this workflow braking drawback I cannot pre-load a specific / single Bookmark but I sure can pre-load whole value like

Tools > Options > Indexes > Properties > Add > Audio Track Count

which then can be instantly utilized by my personal set of audio oriented Bookmarks like

Code: Select all

audio-track-count:<1  
audio-track-count:1  
audio-track-count:>1  

that allow me for pinpointing [accordingly]

mute
mono
stereo or multichannel

files?

[void]

helps during a session for repeated searches by simply storing their results.

Correct, the cached values are kept instead of being thrown out when you close the window.

But if user closes Everything's EXE then the search results are lost for good

Correct, cached values are cleared when you exit Everything.

but I sure can pre-load whole value

Think of indexing properties as a permanent/persistent cache.



Everything will now add hidden windows to History -> Recently Closed Windows.

Hidden windows can be restored from this menu.

[Thy Grand Voidinesss]

So OK

Using that

Tools > Options > Indexes > Properties > Add

I have indexed for myself

● Audio Channels
● Audio Track Count
● Subtitle Track Count
● Video Track Count

and it seems that this works great i.e. now my numerous Bookmarks utilizing these values work instantly even after reset of the operating system

But what about a Bookmark like

Code: Select all

file:!.  

that I use to find fils without extensions; or Bookmark

Code: Select all

dupe:size;name

which seeks duplicates? There is no

Tools > Options > Indexes > Properties > Name > File

value; but there is

Tools > Options > Indexes > Properties > Name > Size

and

Tools > Options > Indexes > Properties > Name > Name

So the first of these two Bookmarks cannot be pre-cached using indexing [and thus this is a limit of what currently Everything is capable of in that matter]; but the second one can be [but it requires indexation of 2 different values it consists of]?

[void]

The type of item is always indexed (eg: file or folder)
The name of the item is always indexed.

Basic file information (size, date modified, attributes) is indexed differently and can be managed under Tools -> Options -> Indexes.

Size and date modified are indexed by default.



dupe: doesn't require property indexing.
Information is gathered as needed.
Indexing properties will improve performance.
eg: dupe:"Audio Channels";"Audio Track Count";"Subtitle Track Count";"Video Track Count"

dupe: can find duplicates of one or more properties.
The name property is used if no properties are specified.

dupe:
Finding duplicates

[Thy Grand Voidinesss]

I went through all of my Bookmarks and expanded the scope of what I index. And I am left with two more unusual cases, for dealing with which I would still require some further help


This one

Code: Select all

size:0 | < startwith:hex:content:00 regex:binarycontent:^\x00*$>

I use to find zero size files / NULLs content. But the only hex property available is Alternate Data Stream Hex, so I reckon this will not make that Bookmark work instantly. Am I right?


I also have such one

Code: Select all

content:mytext: | ansicontent:mytext: | ifilter-content:mytext: | plain-text-content:mytext: | unicodecontent:mytext: | utf8content:mytext: | utf16content:mytext: | utf16becontent:mytext:

with annotation that it is a work-in-progress [as it utilizes this mytext as a searched-for test content]. But for content the are such available properties

● Content Created
● Content Provider
● Content Status
● Content Type

so they seem to also have nothing to do with what that particular Bookmark [attempts to do], right? So I think the question here is: is it currently at all possible to pre-cache all of e.g. TXT files? So that whatever I would like to find [e.g. myothertext] I cold just write it down on the spot and see files containing it instantly? The title of this topic suggest to me that it is possible viewtopic.php?t=13617 but content of that thread somewhat says otherwise