File Type Group Extension Matching Issue

I tried to search for this topic in the manual and the forums and I was unable to find anything that matched. I apologize if this has already been brought up as an issue, or if it is known behavior that is working correctly.

To me this seems like a bug but I'm hoping there's just a setting I need to apply to fix this issue.
It seems like the File Type Groups are matching based on whether the extension is contained anywhere within the file name instead of just checking the extension. For example, if a file of any type contains the string ".mp4" in its name it is going to be considered part of the "Movies" group even if that's not the correct group. Both "i-am-a-movie.mp4" and "i-am-not-a-movie-but-have-.mp4-in-my-name.txt" will be included in the "Movies" group which is not ideal. This forces me to use a file extension check in any find operations or scripts, and it prevents me from using "grp:Movies" in the quick filter since these other files are slipping through.

Please let me know if there is a way to prevent this behavior. When I select "Movies" in the filter or use the "Movies" group in a script or find operation I would have expected it to consider the file extension and not the file name to determine the proper group.

Where are you encountering this problem specifically? That isn't how it normally works, and doesn't behave that way here when I try it.


Your post prompted me to do a little bit more testing and it seems that the issue is not as widespread as I first thought. I was incorrect about the scripting function and the find operation being affected. Both of those are working as expected. I tested by added a script column to display 'Y' if item.InGroup("Movies") and 'N' otherwise and the correct value is being displayed for the text file. The find functionality is also working correctly; only the actual video file is returned when using Type > Match > File Type Group > Movies. So it appears that the only issue is with the filter.

Some more things I noticed in a further test:
The numbers displayed next to the group name in the filter selection is correct but when the group is selected it's including the txt file with ".mp4" in the name. So although it says "Movies (1)" there will be 2 files displayed when applying the "grp:Movies" filter. I also confirmed that it's properly filtering out other file types (e.g. another text file without ".mp4" in the name is not displayed when "grp:Movies" is applied). I must have inadvertently applied some setting that introduced this behavior. Do you happen to know what might cause the filter to behave this way?


I found the issue after digging through the FAYT and filter settings!

The option "Partial matching" was turned on in the section "File Displays > FAYT and Filter Bar Options" of the settings. When I turn that off the File Type Group filtering began to work as expected. I prefer to have that option turned on and it also feels like applying partial matching to a File Type Group is unexpected behavior. When I select a specific file extension the filter is using a regular expression to make sure the match ends with the selected extension. I would expect the File Type Group filtering to behave the same way. At least I know what is going on now.

Thanks for your help in narrowing down the issue!

Edit - One more thing to add:
Selecting "Movies" and another extension also applies the regular expression and fixes the behavior. So instead of just selecting "Movies" I can select "Movies" and "mp4" which results in the filter \.(grp:Movies|mp4)$. Using the filter \.(grp:Movies)$ also works. Selecting "Movies" from the filter options only applies the filter grp:Movies which includes any files with a movie extension in their file name if "Partial matching" is turned on.

A fix for that is being tested. We'd like to test it for a while to make sure it doesn't have any unwanted side effects, since the situation it fixes is fairly uncommon, but we've found the cause and have something in the pipeline.

Configuring the filter bar to use wildcards instead of regex, or turning off partial matching, should avoid the issue for now.