Tracker query by location

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/

1 Like

I think thats not possible at this moment.

1 Like

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.

1 Like

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 :frowning: 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?

1 Like

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! :smiley:

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 :frowning:

Now I remember unsuccessfully trying to re-compile it from those sources circa 2004 (can’t remember what I wanted to change then).

1 Like

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 :slight_smile:

1 Like

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:

  1. All volumes
  2. Selecting a specific volume
  3. Selecting a specific folder. In this case the volume can be determined from the folder selected and hence the query can still be limited to the volume the folder resides on

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 :wink:

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)

1 Like

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 :slight_smile:

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.