I am doing a search with the following criteria:
1. all source files (i.e. *.java,*.xml,*.jsp etc) in a project folder
2. all files in the .metadata directory of the project should be excluded.
To meet the requirements for 2, I know that you can put ",-*metadata*" in "Look in" field, but this criteria is not saved when you store a predefined search.
Therefore, I thought to use the handy dandy "Additional Rules".
I added an additional rule as follows:
(NOT) 'Path[S]' contains "metadata"
PROBLEM:
Adding the above additional rule causes _no_ results to be returned (even files not in the metadata folder).
Am I missing something?
Thanks.
Finder's "Additional Rules" problem (possible bug)
Moderators: fgagnon, nikos, Site Mods
you might have found something there.... i'll have to examine further
but be warned that your alternative is far less efficient than the exclusion filter from "lookin" field. First of all the path is obtained for all items searched and more importantly the finder will get into all folders with "metadata" in their name and examine items only to find them not-matching -- assuming it was working properly of course
but be warned that your alternative is far less efficient than the exclusion filter from "lookin" field. First of all the path is obtained for all items searched and more importantly the finder will get into all folders with "metadata" in their name and examine items only to find them not-matching -- assuming it was working properly of course
Went away for a few minutes and Nikos beat me to it again
Nikos, it seems that 'Look in' info it not saved at all. Is this by design (vaguely remember something being said about this)? To apply the filter to different folders this would be what you want. To be able to specify an exclusion filter, it would be more natural to be able to specify this separately from the 'Look in' specification, of course keeping the speed benefits
As a workaround you could do the following pmike:
Start from the root of your folder hierarchy you want to search. Specify files to search for in the 'Named' box: *.java,*.xml,*.jsp, just as you did before.
In Additional rules specify:
(AND) 'Path[S]' contains "-metadata"
Save as Predefined. That should work.
Since 'Look in' is not saved at all, you won't be able to get to the correct path by just retrieving the predefined filter, so you'll have to start from the right folder each time you want to use this filter on that folder.
Nikos, it seems that 'Look in' info it not saved at all. Is this by design (vaguely remember something being said about this)? To apply the filter to different folders this would be what you want. To be able to specify an exclusion filter, it would be more natural to be able to specify this separately from the 'Look in' specification, of course keeping the speed benefits
As a workaround you could do the following pmike:
Start from the root of your folder hierarchy you want to search. Specify files to search for in the 'Named' box: *.java,*.xml,*.jsp, just as you did before.
In Additional rules specify:
(AND) 'Path[S]' contains "-metadata"
Save as Predefined. That should work.
Since 'Look in' is not saved at all, you won't be able to get to the correct path by just retrieving the predefined filter, so you'll have to start from the right folder each time you want to use this filter on that folder.
Dumb questions are the ones that are never asked 
hey, that's what I was going to recommend as a workaround!(AND) 'Path[S]' contains "-metadata"
anyway, indeed bug confirmed and bug fixed!
not saving paths etc along with the filter is by design. Search is made of 2 things: where to look and what to look for. The rules etc fall into the 2nd category and they can also be used in other things like alt+G and any forthcoming complex visibility filters
which leaves us the "where" bit. Thankfully this is always simpler and could be reconstructed by the drop-down history lists. In the future it will be possible to save composite "search filters" that will include the "where" bit along "what", optionally