"Tidying up" a reference library usually means one of two things: moving files into a better folder structure, or giving up because the folder structure question never has a right answer. Neither is necessary here. Every file stays exactly where you put it — Coii Ref indexes folders in place and never moves, copies or renames anything — so tidiness has to mean something else: a periodic pass that finds what actually needs attention without touching a single file on disk.
Why refiling feels productive and rarely is
Reorganizing a folder feels like progress in a way that tagging doesn't — there's a visible before and after, a satisfying sense of order restored. The trouble is that the order only lasts until the next batch of files arrives that doesn't fit the scheme cleanly, at which point the whole project either needs redoing or gets abandoned halfway, leaving a library that's half the old structure and half the new one — arguably harder to navigate than before the reorganization started. A query doesn't have that failure mode, because it isn't a structure that decays; it's a question asked fresh against whatever state the library happens to be in today.
What refiling was actually trying to solve
The urge to refile usually comes from one of three real problems: things you can't find, things that have drifted stale since you tagged them, or things that are technically duplicated somewhere on disk. Refiling attacks all three by physically reorganizing files into a scheme that's supposed to prevent the problem from recurring — which works for a while, until the scheme itself needs reorganizing. The steps below solve the same three problems with queries instead, which don't degrade the way a folder scheme does, because they're run fresh against the current state of the index rather than baked into a structure from a year ago.
Step 1: Find what's never been touched since it was added
The most common reason a library feels untidy is a backlog of files that were indexed and then never rated, tagged or looked at again — not because they're bad references, but because nothing since surfaced them.
That number is the honest size of the backlog. It's not a problem to clear in one sitting — it's a number worth knowing, and worth working through in bounded slices rather than all at once.
Step 2: Work the backlog in a slice you'll actually finish
Rather than tagging four hundred files in one sitting, narrow to a slice small enough to actually complete — this month's additions, say, or one project's folder.
Step 3: Find references that were rated once and never revisited
A rating from eighteen months ago reflects what mattered then, not necessarily now. A periodic check on old, highly-rated material catches references that are still marked as favourites purely out of inertia.
Step 4: Narrow down likely duplicates without deleting anything automatically
There's no automatic duplicate detection — that's worth stating plainly, since it's the feature people most often expect from a "maintenance" pass. What a query can do is narrow a folder down to files that share dimensions or were added around the same time, which is usually where duplicates actually cluster.
The fuller account of what this app does and doesn't do about duplicates covers the manual check that has to happen after a query like this narrows the field.
Step 5: Check that external drives are actually reconciling, not just missing
If part of the library lives on a drive that isn't always connected, a periodic check that nothing's been silently orphaned is worth running — though the honest expectation is that the watcher handles this on its own once the drive reconnects, rather than requiring the check at all.
Step 6: Clear notes and tags that have gone stale, not the files themselves
A note that says "temp — check before using" from a project that shipped eight months ago is clutter in the same way an unfiled folder is, except it costs nothing to fix: editing or clearing the note doesn't touch the file it's attached to.
What actually keeps a library from going stale
The watcher is doing more of this work continuously than any periodic pass above does. Filesystem events — a rename, a move, a file dropped into an existing folder — become the smallest re-scan that makes the database true again, running in the background without a manual re-import. The queries above aren't compensating for the index falling behind; they're catching up on your own tagging and rating, which is a human backlog, not a technical one.
That distinction is the actual argument against refiling as a maintenance strategy. Refiling tries to solve a structural problem — files in the wrong place — that this kind of library doesn't really have, since search finds a file regardless of which folder it's sitting in. What's left to maintain is purely the metadata layer: tags, ratings, notes. None of it requires touching a file.
Maintenance for a shared or handed-off library
A library one person built and tags consistently drifts less than one that several people touch over time — a freelancer inheriting a studio's archive, or a new hire picking up a predecessor's tagging habits partway through. The queries above double as a way to find where that drift actually happened, rather than assuming it and re-tagging everything from scratch.
That kind of query turns "how much of this library did the last person actually finish tagging" into a concrete number rather than a guess, which matters when deciding whether to spend a week catching up on old material or simply start tagging forward from today and let the backlog stay a backlog. Either is a reasonable choice — the point is that it becomes a choice made with a real number in front of it, rather than an assumption.
Why this holds up even as tagging conventions change
A library maintained over several years rarely keeps the exact same tag
vocabulary the whole time — a scheme that made sense with two hundred
images stops fitting one with twenty thousand, and tags get renamed,
merged or retired. None of the maintenance approach above depends on the
vocabulary staying fixed. A saved view stores the query text and re-parses
it each time it's opened, so renaming wip to in-progress across the
library doesn't leave old saved views silently searching for a tag that no
longer exists — they follow the rename automatically, which is the reason
this whole approach doesn't need re-auditing every time the tagging
convention itself evolves.
A maintenance rhythm that doesn't feel like a chore
The queries above work equally well run all at once or spread across a month, and spreading them out tends to actually happen more often than a single dedicated "maintenance day" that keeps getting postponed. A ten-minute check on a Friday — the backlog query, the stale-favourites query, whichever saved view is due — fits into the kind of small gap a full afternoon rarely does, and it adds up to the same coverage over a quarter without ever feeling like a task competing with actual project work for calendar space.
Scoping a maintenance query to a recent date range like this, rather than running the full-library version every time, is what keeps the habit sustainable — the whole-library sweep is worth doing occasionally to see the true size of the backlog, but the week-to-week rhythm works better against a slice that's actually small enough to finish.
One more thing worth checking: notes that reference a file that moved
A note occasionally mentions another file by name — "matches the angle in the barn shoot" — and if that other file's folder gets renamed or moved around on disk, the note's wording doesn't update itself, since it's plain text rather than a link. It's a small, low-frequency thing to check for during a maintenance pass, not a structural problem, and it costs nothing to fix once noticed: edit the note's wording, and nothing about the file underneath it needs to change at all.
Common mistakes worth avoiding
Treating "tidy" as a folder-structure goal and starting a reorganization project — the whole point of indexing folders in place is that the structure doesn't need to be right, so time spent perfecting it doesn't pay off the way it would in a tool that requires clean folders to search well. Running a duplicate check expecting an automated result — there isn't one, and treating a dimension-and-date query as confirmed duplicates without eyeballing them risks losing something that only looks like a repeat. And doing one enormous maintenance pass instead of small bounded slices — a query returning four hundred untagged files is a number to work through over weeks, not an afternoon to lose to it.
A worked example: the "misc" folder nobody's opened in a year
Almost every long-running library has one folder like this — a catch-all that accumulated whatever didn't obviously belong somewhere else, and that everyone's stopped opening because it's an unsorted wall of thumbnails. The instinct is a weekend spent sorting it properly into the "real" folders. The query-based version skips that entirely.
That number doesn't need to become zero. What it needs is to stop being invisible — tagging even the twenty or thirty files from that set that turn out to be genuinely useful, found by scanning the grid rather than reorganizing the folder, is a better use of an afternoon than physically moving a hundred and eighty-seven files into new homes on the theory that their new location will make them easier to find. It won't; the tag will.
What to do when the library is large enough that maintenance itself needs scheduling
At a few hundred files, a maintenance pass is occasional and quick. At tens of thousands across several drives, the queries above are worth turning into saved views you open on a rotation — a backlog view, a stale-favourites view, a recent-external-drive view — rather than retyping each query when the mood strikes. Indexing and living with a library that size covers the initial scale problem this builds on, and organizing across multiple external drives is the companion piece if the backlog above is split across disks that aren't always connected.
It's also worth backing the library up properly before any maintenance pass that involves reviewing large numbers of files — not because anything here deletes on its own, but because a folder you're actively reviewing is a folder worth having a current copy of regardless. For the honest contrast with a tool that copies files into its own managed library rather than indexing them in place, the comparison with Eagle covers what that trade-off actually buys you, and what "local-first" means in practice is the underlying idea this whole maintenance approach depends on: the files are the source of truth, and the index is just a fast way to search them.
None of the queries above are special or hard to remember — most reuse the same handful of keys covered in the full set of search operators, combined a slightly different way depending on what's being checked for. Knowing that short list well is most of what turns "maintenance" from a vague obligation into a specific, repeatable five-minute habit rather than a recurring dread on the calendar.
The habit this whole approach is trying to build is a small one: check the backlog periodically, clear a bounded slice of it, and trust the watcher with everything else. That's a lighter commitment than a folder scheme ever was, and unlike a folder scheme, it doesn't get harder to keep up with as the library grows — the query returns the current backlog whether it's running against three hundred files or thirty thousand, and it never asks for a weekend to catch up on what a folder rebuild would have demanded of anyone who let the backlog sit for a while before finally getting around to it on some quiet Sunday afternoon.
Try it against a library that already feels untidy — thirty days, every feature, no card and no account, enough to run the queries above against your own backlog and see how large it actually is before deciding whether refiling was ever the fix.