[Bug/Unintuitive Behavior] file: matches against paths when Match Path is enabled

[lifu]

For convenience sake, I like keeping Search > Match Path enabled, but there are cases when I want something matched only against the filename.

In the search syntax instructions, file: is supposed to only match against filenames, not folders. But with Match Patch enabled, if you input file:foo, it will match against files in folders that contain 'foo'.

I think this behavior should be changed so it only matches against filenames even with Match Path enabled.


(( Additionally, I would appreciate having fn: as an alias of file: since I'm used to using wfn: as an alias of wholefilename: ))

[void]

Please try the nopath: search modifier

For example:

nopath:foo

[lifu]

Please try the nopath: search modifier

For example:

nopath:foo

That works, but it still seems like the file: modifier should take precedence over the Match Path setting. There's no indication that it shouldn't in the instructions, and I can't really think of a good reason why it shouldn't.

[raccoon]

It has gotten me, too.

But I recognize now that file: and folder: are more like built-in 'filters' than they are 'modifiers', and it's only by accident that you're allowed to attach a parameter (path or filename) to it. They don't actually take/need any parameter.

E:\MyMusic\ file:
file: E:\MyMusic\
file:E:\MyMusic\
files:E:\MyMusic\

... all need to return the same results.

I recommend @void remove them from the 'Modifiers' section of the documentation, and call them 'Filters'. I would also change the documentation to read files: instead of file:, and folders: instead of folder:.

[void]

From the Everything search syntax:

path: = Match full path and filename.
file: = Match files only.
folder: = Match folders only.


Sorry, I am missing something here.. are you confusing folders with full path? or file with filename?

Files have a full path and filename.
Searching the full path and filename of files can be useful.

There's also a basename: search function in Everything 1.5, which will ignore the path search modifier.
Everything 1.5 makes a few improvements so you don't need to Enable Match Path.

I recommend @void remove them from the 'Modifiers' section of the documentation, and call them 'Filters'. I would also change the documentation to read files: instead of file:, and folders: instead of folder:.

file: and folder: are search modifiers.
If used on their own, they apply to an empty search term.

For example:
E:\MyMusic\ file:
is the same as:
E:\MyMusic\ file:*

I will add a filesonly: and foldersonly: search modifier alias.
Thanks for the suggestions

[void]

Everything 1.5.0.1306 adds the filesonly: and foldersonly: search modifiers.

[raccoon]

@void, could you give me an example where files:<path> and files:<space><path> will produce different results? I'm still a little uncertain about your previous response.

[NotNull]

@void

Do you only want to talk with @void about this, or is it OK if someone else tries to explain it?

[raccoon]

Go ahead NotNull. I was just not addressing the OP.

[NotNull]

could you give me an example where files:<path> and files:<space><path> will produce different results?

They don't. It will effectively be the same search query.

files:<space> can be loosely translated to files:*
This will select all files (not folders) in the Everything database.
(Lousy comparison, but it's a bit like artist: will select all files where the artist property is filled)

Adding <path> will limit the results to all files in that path.
And that is effectively the same as files:<path>


Filters are not part of Everything's core. They are all user defined.
(For convenience some pre-defined filters are distributed with Everything and if one doesn't change the defaults or add to those, there is no need to store them in the user folder (Filters.csv)


Something to think about:
If there was only files:<path> and no files:<space><path>, would you consider files: to be a filter or a modifier?





Regarding OP's question:

There are several interpretations of what a filename is. This is what Everything considers a filename:

Code: Select all

c:\some folder\foo\my document.txt

It consists of several components, separated by a backslash (or forward slash)

When doing a search, Everything searches only the last component of the filename ( my document.txt ) for a match.
If Match Path is enabled, Everything searches all components of the filename ( c:\some folder\foo\my document.txt ) for a match.
In the first case, file:foo will not find a match; in the second case it will.


Many people consider "my document.txt" to be the filename, which is probably the cause of this confusion.

[void]

NotNull explains it well.

files:<path> and files:<space><path> will always produce the same results.

Both will produce the same search OP codes.



What Everything does behind the scenes:
Your search is broken down into search terms with your specified search operators (space = AND, | = OR).
Each search term creates a single search OP code for files and a single search OP code for folders.

files:<path>

This search is parsed as a single search term:
A path search for files only.

Creates a file OP code that tests the full path.
Creates a folder OP code that never matches anything.



files:<space><path>

This search is parsed as two search terms:
A search for all files.
-and-
A path search for files and folders.

Creates a file OP code that matches all files.
Creates a folder OP code that never matches anything.
-and-
Creates a file OP code that tests the full path.
Creates a folder OP code that tests the full path.

Everything ANDs these two OP codes together.

(file OP code that matches all files) AND (file OP code that tests the full path)
(folder OP code that never matches anything) AND (folder OP code that tests the full path)

Everything will optimize out OP codes that match everything or match nothing, so we end up with:

(file OP code that tests the full path)
(folder OP code that never matches anything)

That is, the same OP codes from files:<path>



You can view the search OP codes in Everything in verbose debug mode:

• In Everything, from the Tools menu, under the Debug submenu, click Console
• from the Tools menu, under the Debug submenu, click Verbose
• Type in your files:path search

In the debug console you should find:
FOLDER OPs:

Code: Select all

NOMATCH

FILE OPs:

Code: Select all

 /- MATCH
163
 \- NOMATCH

These are the search OP code trees, leaning on their sides (rotated left 90 degrees).
There is two search OP code trees, one for files and one for folders.

NOMATCH is the root for the folder search OP code tree.
163 is the root for the file search OP code tree. (163 is the OP code for match path / start with only / all ASCII search text)

If we roll these trees over (rotate right 90 degrees), you can see the tree structure a little easier:
FILE OPs:

Code: Select all

        163
       /   \
NOMATCH     MATCH

For files, Everything will execute the root OP code 163 first, if it matches, it moves down the tree to the right (MATCH), if it doesn't match it will move down the tree to the left (NOMATCH)
For folders, Everything will execute the root op code NOMATCH.

MATCH and NOMATCH are real OP codes that end the search for the current item and start execution on the next file/folder.
The MATCH op code adds the current file/folder to the result list.

I hope this help explains what Everything is doing..