Thank you for your feedback Rolf,
I have found Property Indexing (currently only using MD5:) extremely useful. In fact, I am using it extensively on some 200000 picture files.
Here, the indexing takes a while, but that's OK.
Please consider using a tool like shasum256 (or md5sum).
shasum256 will produce a sidecar file (.sha256) so the hash only needs to be calculated once.
Everything has support for .sha256 sidecar files.
After one run, I found that I forgot to add a folder containing many *.mp4 files.
Horror, the indexing starts over from scratch!
The rebuild is required as Everything will only store the MD5 property for files matching your specified property filters.
Everything will reuse the previously indexed properties where possible.
So only new mp4 files should need to be indexed.
Everything only remembers the previously indexed properties when you add exclude filters to your properties.
When adding include filters (eg: *.mp4), Everything must perform a full reindex of your properties.
I will look into keep your existing indexed properties when adding include filters (where possible).
Building the Index is controlled by Include/Exclude Files or Folders, including patterns. OK so far, but any change to the pattern syntax is limited?
The filter syntax is slightly different to the search syntax.
The filter search is simplified for complexity and performance reasons.
(For example, the *.jpg;*.mp4 filter gets compiled into a list of extensions)
The filter search supports wildcards (matches the whole filename) and the regex: modifier
Otherwise, the filter search matches the whole filename.
Accessing bookmarks/filters from filters would be a nightmare as bookmarks/filters can change at any time.
The parameter list should have the same Syntax everywhere, hence as in most cases,
I am not quite sure what you mean here.
The filter search does not support functions.
If you are referring to the normal search, then yes, the standard parameter list syntax in Everything is:
abc;123;"text ; with ; semicolons"
For example:
ext:jpg;mp4
filelist:notepad.exe;explorer.exe
tags:tree;sunny
zipfilenames:everything.exe;everything.lng
I do not really understand what is happening/what's the difference with Find-Dupes: and [Sort:] Dupes: or Unique:, respectively
I can understand the confusion.
These functions have changed every week for the last month.
The syntax I will be recommending now is dupe:<property1>;<property2>;<property3>
For example:
dupe:size
dupe:size;dm
dupe:size;date-modified;name
The functions above will find files where all the specified properties match (within the current results).
dupe:
Forget about find-dupes:
I will keep the find-dupes: function, but I will no longer recommend its use.
(find-dupes: is just an alias for dupe:)
unique:<property> does the opposite of dupe:, that is find files in the current results that have a unique property (removes duplicated properties from view).
unique: only supports one property as the parameter at this stage.
why is can't I write
Path:abc;**def; instead of Path:abc Path:**def
Some functions do not support list parameters.
path: is also a
search modifier.
The correct syntax is:
path:<abc|**def>
-or-
path:<abc **def>
| = OR
space = AND
** implies path:
so you can also do something like:
path:abc|**def
This syntax will also work with most search functions.
For example:
content:<abc|123>
There is also the new
\\ syntax:
def\\abc
-or-
abc\\def
\\ is replaced with **\**
(order is important)
or, this -- see above, with comparison operators:
Path:abc&!def|**efg
Please try the following search:
path:<abc !def|**efg>
path: = enable match path
< > = group search terms
space = AND
! = NOT
| = OR
I will consider a search function to take a semicolon delimited list of paths.