Using Saved Queries and Query Chaining for Recurring Searches

What You'll Learn

What a saved query is, and how it differs from a one-off search
How to save a search so you can run it again with a single name
Re-running, listing, and deleting queries from the CLI and the desktop app
The difference between live queries and frozen --fixed snapshots
How to chain queries with --from-query to build up complex searches in layers
Practical recipes you can copy and adapt

If you find yourself typing the same search every Monday morning - "show me the large videos I added this month" or "which photos still need enrichment" - you are doing work the tool can do for you. A saved query turns a search you have already perfected into a named shortcut you can re-run any time, and query chaining lets you compose those shortcuts into bigger searches without retyping the whole thing.

This guide assumes you are already comfortable writing searches. If structured filters like size:>100MB or enriched:false are new to you, read the Search Syntax Guide first, then come back here.

What a Saved Query Is

A saved query is a named, re-runnable filter set. Instead of remembering the exact combination of filters that produced a useful result, you give that combination a name once, and from then on you run it by name. The search itself - the filters, the operators, the sort order you typed - is stored, not the list of files it happened to match.

That distinction matters more than it first appears. A bookmark to a list of files would go stale the instant you scanned anything new. A saved query stores the question instead of the answer, so it stays useful indefinitely: the question "videos over 500 MB added this month" is still meaningful next month, even though the files that answer it will be completely different.

By default a saved query is live. Every time you run it, FileFortress re-evaluates the stored filters against your current local index, so the results reflect whatever has been scanned since the last time you ran it. A query called recent-videos will quietly start including last week's footage the moment that footage is in your index - you do not have to touch the query. Re-evaluation happens against the local index that FileFortress already maintains on your device, so re-running a saved query is fast and works the same way whether you are online or not.

Why bother saving?

Saved queries remove three small frictions that add up: you stop retyping (and mistyping) long filter strings, you stop trying to remember the exact combination that worked last time, and you turn a recurring chore into a one-word command or a single click. The payoff grows with every repeat - the searches you run most are exactly the ones worth saving.

There is also a fixed variant. A fixed query freezes the set of files that match at the moment you save it, so re-running it always returns the same files even as your index grows. We will cover when each one is the right choice in the Live vs Fixed section below.

Stored on your device

Saved queries live in your local encrypted store (SQLite) on the device where you create them. They are part of your private, on-device metadata - they are not uploaded to your cloud providers and are not shared across your other devices.

Saving a Query

To save a query, run any search the way you normally would, then add --save-query (short form -q) followed by a name. The search runs and shows its results exactly as usual, and the filter set is recorded under that name for next time.

# Run a search and save it under a name
filefortress search "extension:mp4 size:>500MB" --save-query big-videos

# Short form
filefortress search "enriched:false extension:jpg,jpeg" -q photos-to-enrich

Pick a name you will recognise weeks from now. Names like big-videos or photos-to-enrich describe intent; names like q1 or test will be a mystery by next month. Stick to lowercase words and hyphens so they are easy to type and quote safely in scripts.

Refining a saved query is just saving again. If you decide your big-videos threshold should be 1 GB instead of 500 MB, run the improved search and save it under the same name to update the definition. Treat the act of saving as committing the version you are happy with - run the search, confirm the results look right, then attach --save-query with the name you want it to keep.

Saving is not limited to the search command. The find duplicates command also supports --save-query, so a duplicate-detection pass you run regularly can be saved and re-run the same way.

# Save a duplicate-detection pass for re-running
filefortress find duplicates --remote "My Storage" --save-query dupes-to-review

Re-running and Managing Queries

Once a query is saved, you re-run it by name through the same search command. Because a live query re-evaluates against the current index, this is exactly how you check "what is new since last time" - run the same name again and read the fresh results.

# Re-run a saved query by name
filefortress search --from-query big-videos

# Short form
filefortress search -Q big-videos

The same flag that re-runs a query, --from-query, is also the foundation of chaining - we will return to that shortly. For now the key idea is that a saved query becomes a building block you reference by name rather than retyping. If you re-run a query and supply no extra filters, you simply get that query's current results; supply extra filters and you are chaining, which is covered in the next section.

A practical detail worth internalising: re-running a live query is the natural way to track progress on a backlog. Save a query for "files still needing attention", run it today and note the count, do some work, and run it again - the list shrinks because the underlying index changed, not because you edited anything. That feedback loop is the main reason live queries are the default.

Managing Queries in the Desktop App

If you prefer a visual workflow, the desktop app's Search page manages saved queries for you. After you compose a search there, you can save it, see the full list of your saved queries, re-run any of them with a click, and delete the ones you no longer need. There is no separate place to learn - the page you already use to search is also where your saved queries are organised.

The same base-query chaining described below is available on the Search page too. You can pick a saved query as your starting point and add filters on top of it without leaving the page, watching the result list update as you refine. When you arrive at a view you want to keep, save it - and it joins your list alongside the others, ready to re-run or chain from later.

The Dashboard also surfaces your saved queries so the searches you care about most are one click away. This is the fastest path for a recurring check: open the app, glance at the Dashboard, and re-run your weekly query without typing anything.

Same queries, either surface

A query you save in the CLI and a query you save in the desktop app are the same kind of object in the same on-device store. Save one in the terminal and you can re-run it from the Search page or Dashboard later - whichever is more convenient at the time.

Live vs Fixed (`--fixed`)

The choice between a live query and a fixed snapshot comes down to one question: when you re-run this, do you want the current answer to the question, or the same answer you got the day you saved it?

A live query (the default) re-evaluates its filters every time, so the result tracks your index as it changes. A fixed query is created by adding --fixed when you save; it freezes the set of files that match at that moment and will not pick up newly scanned files on later runs.

A useful way to think about it: a live query answers a question ("which files are large videos from this month?"), while a fixed query records a set ("these exact files, as they were"). Most recurring searches are questions - you want the current answer - which is why live is the default and the right choice the vast majority of the time. Fixed is the specialist tool you reach for when the stability of the set itself is what you care about.

# Live (default): re-runs track the current index
filefortress search "size:>500MB extension:mp4" --save-query big-videos

# Fixed: freezes the files matching right now
filefortress search "path:*/2024-archive/*" --save-query archive-2024 --fixed

Situation	Use	Why
"What is new this week?"	Live	You want each run to reflect files scanned since last time
A recurring health check (un-enriched files, duplicates)	Live	The point is to watch the number shrink as you process the backlog
A defined batch you are working through	Fixed	The set should not shift under you while you work it
A point-in-time reference ("the archive as it stood")	Fixed	You want a stable record, not a moving target

A fixed query will not surprise you - or update itself

Because --fixed freezes the matching files at save time, newly scanned files that would otherwise qualify never appear in it. That is the whole point, but it is also the easy mistake: if you fixed a query and later wonder why fresh files are missing, the fix is to save it again as a live query (without --fixed).

Query Chaining with `--from-query`

Chaining is where saved queries earn their keep. When you pass --from-query NAME (short form -Q) to search, the results of that saved query become the base set, and any additional filters you type are applied on top of that base. You are not re-running a search against your whole index - you are narrowing down the results of an existing query.

This lets you define a broad, expensive-to-describe base once and then explore it from many angles. The base query carries the complicated part; the extra filters stay short and readable.

You could, of course, type every filter into a single search and get the same files. Chaining wins when the base is reused. Define "all my videos" once, and every drill-down - the 4K ones, the long ones, the ones in a particular folder - starts from that shared definition. If you later refine what counts as a video, you change it in one place and every chained search inherits the change. That is the difference between a base you maintain once and a long filter string you copy and edit in five places.

A Worked Multi-Step Example

Imagine you manage a large media collection and you regularly want to drill into your video library. Start by defining the broad base - everything that counts as a video worth caring about - and save it once.

# Step 1 - define and save the broad base
filefortress search "extension:mp4,mov,mkv size:>50MB" --save-query all-videos

Now you can layer narrower questions on top of all-videos without repeating the extension and size filters. Each of these searches the base set, not the whole index.

# Step 2 - only the 4K ones, from the base
filefortress search "width:>=3840" --from-query all-videos

# Step 3 - of those, only the long ones (over 10 minutes)
filefortress search "width:>=3840 duration:>600" --from-query all-videos

# Step 4 - narrow further to a folder, and save this refined view
filefortress search "width:>=3840 duration:>600 path:*/Deliverables/*" \
  --from-query all-videos --save-query hero-clips

Notice what happened in Step 4: a chained search can itself be saved. hero-clips now records both the base it was built on and the extra filters, so re-running it reproduces the whole refinement in one name. Build the funnel once, name the useful stages, and you have a small library of related views that all share the same foundation.

Iterate, then commit

A good rhythm is to chain interactively first - add one filter at a time with --from-query until the result list looks right - and only then add --save-query to lock in the version you like. There is no cost to throwing away the intermediate searches; only the named ones stick around.

Practical Recipes

These are starting points - adjust the filters to your own collection and naming. They use only the filters covered in the Structured Filters Reference, so each one is easy to tweak.

New large videos this month

A live query that answers "what big footage came in recently?" each time you run it. Keep it live so the result moves with the calendar and your scans.

filefortress search "extension:mp4,mov size:>500MB modifiedAt:2026-06*" \
  --save-query new-large-videos

Un-enriched photos backlog

A live health check that shows photos still missing local enrichment. As you run your enrichment tools the count should shrink on each re-run, which is exactly why it should stay live rather than fixed.

filefortress search "extension:jpg,jpeg,heic enriched:false" \
  --save-query photos-to-enrich

A narrowing chain for review

Build a broad base of recent documents once, then layer a tighter filter on top to get just the ones worth a closer look. The first query is reusable on its own; the second is a focused view derived from it.

# Broad base, saved once
filefortress search "extension:pdf,docx modifiedAt:2026*" --save-query docs-2026

# Narrow on top of it, and save the focused view
filefortress search "size:>10MB path:*/Contracts/*" \
  --from-query docs-2026 --save-query large-contracts

A frozen archive reference

When you want a stable record of a set as it stood at a point in time - say, everything in last year's archive folder - save it with --fixed. Later scans will not change what this query returns, so it stays a reliable reference rather than a moving target.

filefortress search "path:*/2025-archive/*" \
  --save-query archive-2025-snapshot --fixed

Best Practices

Name for intent, not mechanics. photos-to-enrich tells you why it exists; jpg-false makes you reverse-engineer it later.
Default to live; reach for --fixed deliberately. Most recurring searches want the current answer. Only freeze when a stable, point-in-time set is genuinely what you need.
Put the heavy lifting in the base query. When several searches share a foundation, save that foundation once and reference it with --from-query rather than copying filters around.
Prune what you no longer use. Delete stale queries from the Search page so your saved list stays a short, trustworthy menu of the searches that matter.
Re-run after scans. Since live queries reflect the current index, run them after a fresh scan to see the newest matches.

find query is deprecated

The legacy find query command is deprecated. Saving, re-running, and chaining queries now all live on the search command, which is where all future improvements land. If you have old habits or scripts built around find query, move them over to search with --save-query and --from-query.

Search Syntax Guide - The operators and patterns your saved queries are built from
Structured Filters Reference - Every metadata filter you can put in a query
search Command Reference - Full reference for the command, including --save-query, --fixed, and --from-query