Query term order shouldn't matter, but does.

[humdinger]

This is hrev57849, 64bit.

The order in which you enter the terms for a query should not matter, but apparently it does. Consider these two queries that should have the same result:

1. query -a "(((MAIL:when>%-3 days%)&&(MAIL:subject=="*[cC][oO][mM][mM][iI][tT]*"))&&(BEOS:TYPE=="text/x-email"))"

2. query -a "(((MAIL:subject=="*[cC][oO][mM][mM][iI][tT]*")&&(MAIL:when>%-3 days%))&&(BEOS:TYPE=="text/x-email"))"

While query 1 results in the correct few dozens of mails from the last 3 days, query 2 returns over 3,000 mails from since forever (2019 for me, as I don't have older mails on this computer).

Not good...

[humdinger]

B_OK

[humdinger]

B_NOT_OK

[waddlesplash]

Does this reproduce on something besides BFS with emails; perhaps on packagefs?

[humdinger]

With "on packagefs" you mean like the "system" volume?

There isn't much with atributes around there...
I just searched for applications with a "sk" AND "b" in their name, then tried the other way around. That did work. As did searching for audio files on a BFS volume, querying for Artist && Album combinations.

Maybe it's somethingto do with the MAIL:when attribute not being of type "string" as the MAIL:subject?

Also curious, why does query -a "(last_modified>%-1 days%)" spit out every file, not just the ones modified since yesterday? Maybe worth another ticket...

[waddlesplash]

It's possible that relative date-based queries are somehow broken and that's the problem here.