Ok.. not sure if this is a bug or not... but I reported this in the tips/tricks section (viewtopic.php?f=3&t=8569) because I was not getting the results I expected from a search... from discussing it there, it seems like the search function goes off the "system" filename listing and does not respect the Natural Numeric Sort setting. This is causing my sort to fail.
Here is the example:
Name: : >= 9450.htm AND < 10500.htm
folder: \\Network\PT\REQ
Contents tab: the
My folder holds files 1.htm through 10900.htm
If I search from 9000.htm through 9999.htm... everything works ok.... but - if I search from 9000.htm through 10000.htm - it fails.
My guess is this has to do with how windows actually stores the files and filenames with 10000.htm falling in place BEFORE 9999.htm in the system - even though it has a higher number and the filename sort does show it re-sorted in the correct numerical order. I noticed that when I first open a tab with this network location, the filenames appear in the "system order"... 1.htm, 10.htm, 100.htm....10000.htm, etc... then the system resorts the order based on the Name column in the "correct" numerical order.
I have the General->Sorting->Natural numeric sort order checked... so, my thought is that the Find Files should also reflect the Natural Numeric Sort option so if checked, the search will reflect that as well and the correct results will display... perhaps an option within the Find Files Tab to override the setting? Thoughts?
Thanks!
Find Files: search not using Natural Numeric Sort settting
-
- Posts: 20
- Joined: 04 Mar 2012 20:56
-
- Site Admin
- Posts: 60563
- Joined: 22 May 2004 16:48
- Location: Win8.1 @100%, Win10 @100%
- Contact:
Re: Find Files: search not using Natural Numeric Sort settti
These >= and <= operators currently do an alphabetical string comparison, hence your results.
It might be an idea to make it sensitive to natural numeric sorting, but I think your case is quite rare. Low priority, I'm afraid.
It might be an idea to make it sensitive to natural numeric sorting, but I think your case is quite rare. Low priority, I'm afraid.
FAQ | XY News RSS | XY Twitter
-
- Posts: 20
- Joined: 04 Mar 2012 20:56
Re: Find Files: search not using Natural Numeric Sort settti
Bummer.... think the help section might need to be clarified a bit.. because I took the statement below to mean I could so this exact Find Files operation on numerics:
Oh well.. off to find some other search software that allows file searching with date ranges.
Would think that this would allow you to use the find files to search on the "logical numeric order" for filenames with digits... not sure how this is any different than alpha filenames in reality and makes the Find Files options more limiting than it needs to be.When numbers are compared it's about numerical values.....
Oh well.. off to find some other search software that allows file searching with date ranges.
Re: Find Files: search not using Natural Numeric Sort settti
Where did you look in help? I don't find...pesto12601 wrote:Bummer.... think the help section might need to be clarified a bit.. because I took the statement below to mean I could so this exact Find Files operation on numerics:Would think that this would allow you to use the find files to search on the "logical numeric order" for filenames with digits... not sure how this is any different than alpha filenames in reality and makes the Find Files options more limiting than it needs to be.When numbers are compared it's about numerical values.....
Oh well.. off to find some other search software that allows file searching with date ranges.
But in
Help / Advanced Topics / Scripting / Comparisons
you find how to differentiate between numbers and strings - especially that (for example) "10a" is not numeric.
Win11 Pro 223H2 Gerrman
-
- Posts: 20
- Joined: 04 Mar 2012 20:56
Re: Find Files: search not using Natural Numeric Sort settti
I had found it under
Help>Find Files Name>Name>Comparison Operators -- the whole text is here:
I agree that "10a" is not numeric.. but 10001 is and (IMO) should be able to be used as a search operand. The only problem here is how Windows groups filename in a non-numeric order and even though XY can resort into the "logical numerical order", that same sort is not used to search files... I do have a unique situation, one I'm sure doesn't come up often, but was hopeful I didn't need to buy/use further softwareto solve my issue.. especially since I move between multiple target paths and the "Auto-sync" option in Find Files fits perfectly here.
In any event.. found PowerGREP which does all that I need and more... cost a bunch though so I'm still looking for other options... but - nice piece of software in any event!
Help>Find Files Name>Name>Comparison Operators -- the whole text is here:
Perhaps I am taking it out of context.... don't know...Comparison Operators
The Name field supports comparison operators. This means you can e.g. list all files from A to M.
< Less than
> Greater than
<= Less than or equal to
>= Greater than or equal to
The operators must be surrounded by spaces and are prefixed to the patterns.
Examples
When strings are compared it's about alphabetical order. Find all files before "m":
< m
Find all items from "d.txt" through "m.txt". Watch the double space after AND: Boolean " AND " must be surrounded by spaces as well! The leading ":" is the inline Boolean search mode marker.
: >= d.txt AND < m.txt
When numbers are compared it's about numerical values. Find all items whose full name (incl. path) is longer than 100 characters:
len: > 100
Notes on using Comparison Operators
· Patterns with comparison operators should not contain wildcards; they make no sense here anyway and will just be treated as characters "*" and "?" in the comparison.
· The settings "Whole words" and "Fuzzy" are ignored with patterns using comparison operators. But, of course, the settings are applied with non-comparison-patterns. E.g., with "Whole words" enabled, the following term will match "a d.txt" but not "ad.txt", and not "d a.txt" (because it's > c.txt):
:a AND < c.txt
In words: Find all items that contain "a" as a whole word, and are alphabetically sorted before "c.txt".
· It does not make sense to combine comparison operators with RegExp patterns; the RegExp will not be analyzed but simply be used as a string in the comparison.
I agree that "10a" is not numeric.. but 10001 is and (IMO) should be able to be used as a search operand. The only problem here is how Windows groups filename in a non-numeric order and even though XY can resort into the "logical numerical order", that same sort is not used to search files... I do have a unique situation, one I'm sure doesn't come up often, but was hopeful I didn't need to buy/use further softwareto solve my issue.. especially since I move between multiple target paths and the "Auto-sync" option in Find Files fits perfectly here.
In any event.. found PowerGREP which does all that I need and more... cost a bunch though so I'm still looking for other options... but - nice piece of software in any event!
Re: Find Files: search not using Natural Numeric Sort settti
I think your place to find help was pretty good.
(As scripting-fan I automatically searched there...)
But I also think what is compared is "9450.htm", and this is a string, not a number.
And even if you only compare with "9450" the filename compared with is a string. So it always will be string-compare.
(As long as Don will not add "natural numeric compare" like "natural numeric sort" )
(As scripting-fan I automatically searched there...)
But I also think what is compared is "9450.htm", and this is a string, not a number.
And even if you only compare with "9450" the filename compared with is a string. So it always will be string-compare.
(As long as Don will not add "natural numeric compare" like "natural numeric sort" )
Win11 Pro 223H2 Gerrman
-
- Posts: 20
- Joined: 04 Mar 2012 20:56
Re: Find Files: search not using Natural Numeric Sort settti
Thanks Peter - I think the problem here is the way the system searches the files as you mention... hopefully, a natural number search will be added down the road - think it would be less confusing to the user as "naturally" a filename such as 1000.x should be considered as coming after 900.x - I guess that is why the natural numeric sort was added in the first place.