Search including \subdir\subdir\ not working

[jonathanpoulin]

I would like to add also that the help file is still confusing/wrong about the current implementation.

Here is a comment from white, back in 2022:

The text is however very unclear and seems to be wrong. Or I don't get it. You can only include or exclude folder names, not partial paths as far as I know. So this seems to be a bug in the Help.
2ghisler(Author)
Please confirm.

Re: cm_SearchFor No files found

[tuska]

2jonathanpoulin
Thanks for the info.

After trying again:
- Enter search term ('Everything' 1.4 does not find anything for me due to missing parameter)
- Tick "Match path when a search term contains a path separator"
... 'Everything' 1.4 suddenly finds both .ini files with and without inverted commas.
(Probably 'Everything' 1.4 was busy with something else during the previous queries, who knows ).

> I know this is not a topic about Everything ...
No problem, I just wanted to express earlier that we shouldn't go too far off topic
regarding 'Everything' (e.g. indexing) in a bug forum if the topic concerns a search in TC.

[white]

It is very good and pleasant to hear that a more reasonable solution can be proposed on your part.
and perhaps your pseudocode will be the most balanced solution. I hope at least for that.
The current implementation is definitely no good.

2AntonyD
2jonathanpoulin
Did you notice the referenced thread continued on page 2 with this post:

The reason is simple: ...

I think the behavior is not intuitive and not consistent. I made a suggestion to improve it here:
https://www.ghisler.ch/board/viewtopic.php?t=77493

If you like the suggestion you can add your support for it.

2jonathanpoulin
Did you notice that the ↑ symbol contains a link to the quoted post?

I would like to add also that the help file is still confusing/wrong about the current implementation.

That's why I created the wiki page, to hopefully make things more clear.

[jonathanpoulin]

Did you notice the referenced thread continued on page 2 with this post:

Oh, nope, I did not see that. Thanks for the heads up.

If you like the suggestion you can add your support for it.

I just read it thoroughly and replied to add my support.

Did you notice that the ↑ symbol contains a link to the quoted post?

Nah, I did not. Thank you for letting me know. But, in my last post, the link I put there is a "link to hightlight".
This:
https://www.ghisler.ch/board/viewtopic.php?p=420284#p420284:~:text=The%20help%20text%20you%20refer%20to%20is%20about%20the%20%22Search%20for%22%20field.%20 ... %20confirm.

That's why I created the wiki page, to hopefully make things more clear.

Yes, I know. I need to check that more... LOL! But, I think the help file (the .chm) should be fix. Isn't it

[AntonyD]

I think the help file (the .chm) should be fix. Isn't it

Of course, yes. Because I still have to admit but - people are much more likely to read the help in their native language.
And since the CHM help is translated into many languages, the probability that more people will read it increases greatly.
And an online wiki - of course, it adds usefulness, but still you need to know very well and remember that there is such
a resource at all.

[petermad]

but still you need to know very well and remember that there is such
a resource at all.

In My Extended Menu under help I have a direct link to the Wiki - the same could be put in the official menu files.

And since the CHM help is translated into many languages

There are only help files in 9 languages (apart from English and German) - and of these only 2 are almost up-to date (2023).

The Chinese chm file, which will probably be readable to the largest population in the world, is for TC 9.12 (2017).
The Spanish chm file, which also covers a lot of people, is for TC 6.5x (2006)

[jonathanpoulin]

And an online wiki - of course, it adds usefulness, but still you need to know very well and remember that there is such
a resource at all.

Exactly what I am thinking!

[jonathanpoulin]

In My Extended Menu under help I have a direct link to the Wiki - the same could be put in the official menu files.

Great idea! I support it!

[jonathanpoulin]

There are only help files in 9 languages (apart from English and German) - and of these only 2 are almost up-to date (2023).

The Chinese chm file, which will probably be readable to the largest population in the world, is for TC 9.12 (2017).
The Spanish chm file, which also covers a lot of people, is for TC 6.5x (2006)

At least first, English and German help files should be fixed. I have not found a lot of errors.

[ghisler(Author)]

The reason why it behaves this way is that the search filters which search for subdirectories are applied to the found directories. This makes sense when using exclude filters, e.g.
*.ini | \usbhub\04*\
Here the search function looks for *.ini files in the current directory. Then it checks each subdirectory whether it is forbidden or not. When it encounters the subdirectory "usbhub", it sees that it isn't forbidden, so it starts searching within usbhub.
Now when it encounters a directory starting with 04, it sees that 04* is forbidden and doesn't go down into the directory.

With a positive filter like
*.ini \usbhub\04*\
this does not work well, because the filter tells the search function that only \usbhub\04*\ are allowed directories. The search function searches the current directory, but none of the encountered directories matches \usbhub\04*\ - therefore it doesn't go into any subdirectory.
I think that it would be a good idea to handle this special case. It could be handled like this:
When no directory matches the search filter, then TC checks whether it matches the filter with the last part (and second-last, third-last etc.) removed, e.g.
*.ini \usbhub\
If it does, then TC searches that directory, but only looks for subdirectories in it, not for files. Now when it finds a directory which matches the original filter, it searches that subdirectory for both files and more subdirectories.

I will not add this for a not rooted filter like
*.ini usbhub\04*\
because it means that TC would have to search trough all subdirectories. For that, the user will have to use:
*.ini \**\usbhub\04*\

[white]

Moderator message from: white » 2024-07-15, 19:03 UTC

Merged this post into this topic because it was posted in [TC11.03] cannot access shared drive from within VirtualBox VM, I assume by accident.

[AntonyD]

And I have a strange misunderstandings: WHY when we use some sub-paths like \usbhub\04*\ internal code of the TC
decided to SPLIT the "indivisible whole": "sub-path"???
Int.Code should just to inspect the string and "to understand" that the entered value is a sub-path in a form of masked DIR-path.
Which means that ALL next operations int.code now makes INSIDE this(those) dir(-s) on which this sub-path is pointing!
like: getCurrentPath()+"\usbhub\04*\".

[white]

With a positive filter like
*.ini \usbhub\04*\
..
..
I think that it would be a good idea to handle this special case. It could be handled like this:
When no directory matches the search filter, then TC checks whether it matches the filter with the last part (and second-last, third-last etc.) removed, e.g.
*.ini \usbhub\
If it does, then TC searches that directory, but only looks for subdirectories in it, not for files. Now when it finds a directory which matches the original filter, it searches that subdirectory for both files and more subdirectories.

Yes, that's the pseudo code I had in mind. But what exactly do you mean by:

Now when it finds a directory which matches the original filter, it searches that subdirectory for both files and more subdirectories.

In my opinion if a subdirectory matches a positive filter, this directory and all subdirectories should be searched with the search text without the positive filters (but with the negative filters). Because if a directory is supposed to be included, it makes sense that all subdirectories are included as well (except when they match a negative filter).

I think the current behavior is actually a bug because of the following reason. Suppose you have 2 positive filters a\ and b\. Then both folders names "a" and folder named "b" will be traversed. Which means these filters are OR-ed. Not only the folders "a" and "b" are traversed, but also all subfolders. So the subfolders are also included by the filter. But you apply the filters again to subfolders. For example, in folder "a" you only traverse subfolders "a" and "b" and no other folders. So subfolders of "a" that were already filtered are AND-ed with the filters again.

\a\	This folder is included because it matches filter "a\" OR filter "b\"
\b\	This folder is included because it matches filter "a\" OR filter "b\"
\a\a	This folder is included because it matches (filter "a\" OR filter "b\" for the parent folder) AND (filter "a\" OR filter "b\"` for the subfolder)
\a\c	This folder is not included because it does not match (filter "a\" OR filter "b\" for the parent folder) AND (filter "a\" OR filter "b\"` for the subfolder)

I will not add this for a not rooted filter like
*.ini usbhub\04*\
because it means that TC would have to search trough all subdirectories.

Why not add it? If he specifies that, that is exactly what he expects. If a "not rooted positive filter" is included, it should search through all subdirectories.

For that, the user will have to use:
*.ini \**\usbhub\04*\

Then the "not rooted positive filter" continues to operate in a non-intuitive and inconsistent way, which is bad.
And it doesn't require any additional code. You could simply let TC add "\**\" internally.

[ghisler(Author)]

This should be working in Total Commander 11.50 beta 1, please check it!

15.07.24 Fixed: Searching for \*\*\ will now find files in the current directory plus those two levels deeper (32/64)

[white]

18.07.24 Added: Search for *.ext test1\test2\ (no backslash at the beginning) will now find files *.ext in directory test1\test2 (in addition to current directory) any levels deep, e.g. c:\startdir\test3\test4\test1\test2\somefile.ext (32/64)
15.07.24 Fixed: Searching for \*\*\ will now find files in the current directory plus those two levels deeper (32/64)

There are bugs, but I first want to discuss the way you implemented this. You disregarded my suggestion to also include subfolders when using an include mask. I will again make my case using a different wording.

When you use search in Total Commander, it defaults to searching in the current folder and all its subfolders.
You can limit the search in its subfolders by using include masks and exclude masks.
When using an exclude mask and specify 1 specific folder, it will exclude that subfolder and all its subfolders.
When using an include mask:

• My suggestion is: When using an include mask and specify 1 specific folder, it will only include that subfolder and all its subfolders.
• Your implementation is: When using an include mask and specify 1 specific folder, it will only include that subfolder but not its subfolders.

I think my suggestion is generally more useful, more intuitive, and more consistent because TC defaults to searching in the current folder and all its subfolders.

My suggestion would require an extra exclude mask if you would not like the subfolders to be included as well.
Your suggestion would require the use of a solution like \**\ to include the subfolders as well.

Examples:

Code: Select all

Search for: totalcmd\
Search in: c:\

Suppose there is only 1 folder named "totalcmd" on drive c: and that is the program folder of Total Commander.

• My suggestion is that the example code would find, in addition to all files in the root folder c:, all files/folders of TC's program folder and all its subfolders.
• Your implementation finds, in addition to all files in root folder of c:, only the files/folders of TC's program folder but not its subfolders.

---

Bug descriptions.

In Windows Sandbox, I installed Total Commander in the default folder (c:\Program Files\totalcmd\).
I search in "c:\" for the following searches:

Code: Select all

"\program files\totalcmd\"

Works as the way it is implemented now.

Code: Select all

"program files\totalcmd\"

The contents of the totalcmd folder is not found.

Code: Select all

totalcmd\

The contents of the totalcmd folder is not found.

Code: Select all

\*\totalcmd\

Works.

Code: Select all

\**\totalcmd\

Does not work.

More complicated examples also fail, but that may be caused by the same thing. It is probably better to fix this first and see if that solves all the problems.