Queries don't work with special "parsedate" terms

[humdinger]

This is vmware hrev28717.

A query for 'All files and folders' 'by Attribute' 'Modified after' "-20 hours" [formula: (last_modified>=%-20 hours%)] should only list those files that were modified within the last 20 hours.

Not here. It lists what looks like very file in the system. In case I'm messing up 'after'<->'before', if I change to 'before' the list is empty.

Thread on the mailinglist: ​http://www.freelists.org/post/haiku-development/Querying-all-file-changed-since-10-minutes-ago-was-Where-are-the-Sounds-preference-settings

[humdinger]

I just tried again, and it does seem to work now, somewhat.
I queried for all files modified "after -5 minutes" and got a few files back that where touched at shutdown a few minutes ago. OK!

Now I waited for a few minutes, expecting to see files vanishing from the live query. Only, they didn't... I edited the query (ALT+G) and hit return, just to manually update it. The "Search" button became engaged and stayed so for a few seconds (odd...), but after the panel closed itself, the query result window was left unchanged, although the modified timestamps of the files lay now 10 minutes in the past.

Only when I close the old result window before clicking the "Search" button, a new correct query is started, returning only the files modified in the past 5 minutes.

A similar experiment with the Name attribute worked as expected, changing/adding files worked live.

[axeld]

The queries are not live in the sense that relative times are constantly updated - this is sort of a missing feature, that one might one to add some day (that would be a manual Tracker feature, then, though, the query at the file system doesn't know about times).

Eventually, the changed query did not update the query string, in which case the files wouldn't change either. However, the long wait time sounds like a bug to me - can you open another ticket for this in case it's reproducible?

[bga]

This is because "after -5 minutes" will be resolved to a fixed point in time when expanded (let's supposed it is 01:05 now. "after -5 minutes" will be replaced by the equivalent to "greater then 01:00") so even the files you expected to disappear still satisfies the query.

Even if this was not the case, the file would not leave the query window as query notifications are triggered on filesystem changes and no change happened to the file. A solution using a build in timer in the QueryPoseView (or something similar) would not be feasible as either you would have to have one timer per Pose or you would need to check all Poses every, say, 1 second, to see if they still satisfy the query or not. This may seem simples but there are some nasty corner cases and would be way too expensive if the query resulted in may Poses.

[humdinger]

Thanks for these explanations[[BR]] I opened a new ticket for that other problem: #4219

Since the original problem of this ticket was apparently fixed with the recent changes to the date parsing, I guess, I'll close this one as fixed.