I am trying to organize my music using Tracker queries. This is mostly working great, as I have tagged my music with proper BFS file attributes, so I can use queries to filter by artist, genre etc.
But It is currently finding all audio files on my disk. I can limit it to a specific disk, but I would like to limit searches to specific folders only. s it possible to have a query look only in e.g. /boot/home/Music/
I think thats not possible at this moment.
Is there a solution over the terminal?
Digging a bit through Haiku sources I found code for a utility called āfilteredqueryā (see bin/filteredquery/query.cpp.
Itās the standard query utility extended with some path filtering. This utility does not seem to be included in the builds, but the code shows it does support filtering by folder. But it does the filtering itself on the result from BQuery. That indicates that the queries themselves indeed donāt support filtering by path.
I added a feature request at #18156 (Support BQuery filtering by folder) ā Haiku
Outside of my current use case of finding my music I often have the desire to limit my file searches to certain folders only, so I think this would be a beneficial enhancement.
Previously i was told, queries arenāt searches, therefore if i want to search stuff, i should use Trax. Sadly i wasn1t able to compile it on Haiku. Maybe you should try that.
If thatās true itās a bit unfortunate that Tracker uses them for searching 
On the other hand I donāt really see why the query functionality should not be used for searches, that argument quite frankly seems to be a bit nonsense.
Anyway, I could try Trax, but never heard of it. Do you have any pointers where this is available?
More knowledgable people should chime in here, but I think the queryās limitation WRT folders is a feature of BFS.
I suppose Tracker could do something similar as the filteredquery you found. Do a query first, then filter for paths. After all, you can do that manually by showing the āLocationā attribute and use type-ahead-filtering to just show some folder (though that might include some false positives).
Tracker could add a āFoldersā item in the āOnā pop-up menu to let you select folders to filter for.
WRT yourspecific problem, you could create a disk image and move your music there. Then, if youāve mounted it, itāll appear as a ādiskā in Trackerās āFindā¦ā window.
More complicated: you could create and index a custom attribute that you add to all your music files and then query for.
The suggestion that Tracker should do the filtering was also what @PulkoMandy wrote on the ticket I created. Also pointed out that there is no performance advantage of doing this as part of the query itself.
Also thanks for the suggested workarounds. The custom attribute is something that should work for me, Iāll try that.
Thanks for reminding me of TraX!
I remember using it back in the BeOS R5 PE days. it was hella fast! 
The sources seem to be missing all the code related to āSettingsā (TraxSettings class, SettingWindow, etc).
There are .zips containing BeOS binaries over PulkoMandyās archive, which also includes the source codeā¦ but those seems to also be missing the āSettingsā part
Now I remember unsuccessfully trying to re-compile it from those sources circa 2004 (canāt remember what I wanted to change then).
TraX v. 1.1 binaries works fine on Haiku 32 bit. Would be great to have on 64 bit too.
That was more as a workaround until we can fix the query user interface.
Calling a ālimitationā a āfeatureā? Itās a design limitation. Queries work like a database and they just return all matching files. There is no performance improvement to filtering by path.
So, from the implementation point of view, you have to run the query on the whole disk, and then filter out the results by path (just like filteredqueries does).
Maybe letās stop piling hacks together and have a look at actually fixing this 
Fixes are always preferred. But as you know, that can take years sometimes. I was suggesting a workaround that people can try right now.
Iām thankful for both the suggestions for a workaround I (and other users) can utilize now and for the considerations on how to best address the issue in Haiku itself.
My 2 cents on the software side: If there would be a performance benefit (which I had implicitly assumed to be the case) it would make most sense to implement this on the query level. If not it can be handled by the application of course. But in any way exposing this functionality in the Tracker UI would be really useful.
Not entirely sure how this would be best presented. Iād probably just expose a single optional folder selection. Maybe UI wise this could be combined with the existing volume dropdown as an additional āChoose folderā option. That way you would have basically three possible selections there:
Iād like to have a ui to rightclick in a folder to ārun querry hereā aswell.
A performance increase would likely be possible with a bfs2 if we ever make that 
Newer filesystems have lots of nice things BFS could profit from, like checksumming of all blocks, transparent encryption, a filesystem level tree of blocks (which could be used to restore files to previous versions and such, by knowing what the previous tree configuration was)
Before we start worrying about that, maybe we should implement it using the existing queries and see how that goes. Since queries are already pretty much instant (as fast as listing a directory), I donāt think there is much performance problem to worry about here
As for advanced filesystem features (such as versionning and backups), I know this exists in btrfs and zfs but I think the integration with the desktop and command line interface isnāt that good yet. Surely something we could experiment with, but maybe letās start by making the most of the features we already have
I will add a GSoC idea for Tracker search window refactoring. I think besides whatās discussed here we already have a few tickets about it, with good UI mockups of places we could go. Which makes it possibly a good, well-defined GSoC project.
Is it possible then to merge Trax to the Tracker search window while refactoring it?, that way there is no need to modify anything to how the queries work?
No, I think queries with directory filter is an useful thing, and TraX is a different useful thing (it is basically a GUI for the command line tool āfindā). TraX does require browsing through all the searched files and directories, so it will be as slow as searching on other systems. Thatās not what we want to provide as the main search interface, even if it is good to have it when you really need it.