[Build 925 64-bit donor] Search subfolder filter / regex / use full path NOK

[kino]

Hello,

It used to work, it does no more (I can't tell on which build exactly this started to malfunction)

.{50} regex should bring all items whose fqn is 50 chars long but it doesn't (it seems checkbox is not taken into account and only subfolder name is filtered)

This feature is extremely useful to spot full paths larger than 260 chars (regexp = .{260,})

Thanks

K.

[kino]

...also, it seems one now needs to add embed File name between wildcards/jokers (e.g. : *searched_filename*) as if implicitly, File name field should necessarily match the whole file or path string (it used to implicitly be a part of the whole string, ^ and $ markers in regex would allow to explicitly specify beginning and ending of line)
right ?
Thx.

[Marek]

.{50} regex should bring all items whose fqn is 50 chars long but it doesn't (it seems checkbox is not taken into account and only subfolder name is filtered)

It seems to work for me for the following definition:

...also, it seems one now needs to add embed File name between wildcards/jokers (e.g. : *searched_filename*) as if implicitly, File name field should necessarily match the whole file or path string (it used to implicitly be a part of the whole string, ^ and $ markers in regex would allow to explicitly specify beginning and ending of line)

Could you provide some screenshot with your search dialog, how do you define the search? (you can send me an email too)

[kino]

Hello Marek,

(a one-liner to get the chance to thank you once again for this incredible tool I'd die without)

I figured out there's no bug but most likely :

• an inconsistency between file search normal versus regex modes (it has not always been that way)
• and I also hadn't perfectly understood that full subfolder search wasn't a full path search (as in full qualified name)

Let me illustrate :

...shows my test set whose subfolder length is precisely 71 chars long
if I set my regex to .{72} it brings nothing as a result -> conforming to subfolder length, not fqn, all right, 'got that
any lower value like .{70} also returns my test set (contained a fortiori -> normal)

Conversely, with regular file search (i.e. : normal, no regex), I need to put wildcards if I want to match (whole line) :

...and without * wildcards, filename is not found:

(I'm pretty sure it wasn't that way until recently as searching for a simple string in filename was just about dropping that string in search field)

Conclusion :

1. I suggest rolling back normal (non-regex) fields to be implicitely about being contained / part of the lines matched
2. I suggest (feature request) an extra checkbox to check the full path including file name (FQN) instead of just subfolder name or full path
   Use case : this would typically be useful for spotting FQN longer than 260 chars when building Joliet CD images

What do you think ?

Thanks

K.

[Marek]

with regular file search (i.e. : normal, no regex), I need to put wildcards if I want to match (whole line) :

In the search dialog please check the menu "Options->Add wildcards to file name" - this option is per default active.

[kino]

bad bad me ! I know I should read the Fine Manual more often but, hasn't it changed along the course of revisions ?
Well, nice, I did alter my config and it now works fine like before ; thanks for your help.

'hope you will consider my Feature Request about providing an option for FULL QUALIFIED NAME search on subfolder path Filter
(including filename and extension up to disk drive letter)

Many thanks !
K.

[kino]

Hello,

I've spotted the new feature in build 928 (filter size upon full path length)
I feel unfortunately that it's more demanding in terms of widgets for less capability than good'ol regex expressiveness.

My CD burner, as an instance, complains building an ISO/UDF image where relative paths from root folder exceed 260 chars in length.

I'm way better off searching for exceeders through the following regex :

Code: Select all

C:\\MY\\ROOT\\FOLDER\\.{260,}

...than computing myself the length of that root folder to subtract it from the total (as a relative root) and still having to deal with filenames length separately from full folder path.

Conversely, a simple "FQN" filter check option (reusing folder input text field) that would apply to the whole path including drive letter, folder path, filename + extension would perfectly do the trick.

If ever that can be implemented, it'd be great !

Thanks

K.