Turning folders you already have into one searchable library

The outcome here is not a new library you migrate into — it's your existing folders becoming searchable exactly where they already sit. That distinction matters because it changes the whole shape of the work: nothing gets copied, so there's no import to babysit and no second copy of anything to keep in sync afterward. What follows is the order that actually works, in the same sequence most people end up doing it in whether they planned it that way or not.

Most of the friction in "building a library" comes from tools that treat it as a migration — move everything into a new structure, then start using it. Indexing in place removes that step entirely, which is the whole reason the job takes an afternoon rather than a weekend even for a genuinely large collection. It also means the project can never really fail halfway: at every point during the process, your original folders are exactly as intact and exactly as usable in Finder as they were before you started.

That reversibility is worth stating plainly, because it changes how much caution the whole process needs. There's no step here that requires confidence about the final structure before you begin, no point where an early decision locks in a later one, and nothing that can't be undone simply by not registering a root, or by removing one you registered by mistake. The worst outcome of getting a step wrong is redoing that one step, not redoing the whole library.

Step 1: Take stock of where the images actually are

Before touching the app, write down the roots: the internal drive folder you've used for years, the external drive with three seasons of client work, the folder a collaborator sends things into by hand, the downloads folder that quietly became a reference archive without anyone deciding that on purpose. Most people have three or four of these rather than one tidy tree, and that's fine — a workspace maps to a folder, not to "the whole library," so several roots become several workspaces rather than a problem to solve first.

It's worth being honest about this list rather than a tidied-up version of it. The folder named after a client from three years ago and the one called "misc" both belong on it. Leaving one off because it's embarrassing just means that folder stays unsearchable, which defeats the purpose of doing this at all. Nobody sees this list but you, and the whole point of indexing in place rather than curating an import is that the folder doesn't need to earn its way in.

Step 2: Index each root separately

Point the app at the first folder and let the initial pass run. This is a read-only pass over what's there — dimensions, EXIF and colour — not a rewrite of anything, so it's safe to run against a folder you also keep open in Finder at the same time, and safe to run while you keep working in it. Repeat for each additional root, including the external drive, once it's connected.

Contrast this with how some tools build a library: Eagle's own documentation confirms it copies files into its library on import, so the folder you imported from and the library Eagle now shows you become two different things that can drift apart the moment either one is edited without the other. Indexing in place is the opposite choice, and it's the reason a folder you're still actively adding to doesn't need to be re-imported every time something changes — the full comparison covers what each approach costs and what it buys in more detail than fits here.

The order across multiple roots doesn't matter much for the outcome, but it's usually easiest to start with whichever one is smallest, so the first pass finishes quickly and you get a feel for what the process looks like — how long a pass over a few thousand files takes on your particular machine and drive speed — before pointing it at the largest one. There's no requirement to finish one root before starting another; multiple workspaces can index independently.

Step 3: Verify the first pass caught everything

A quick sanity check before relying on the index: a broad, type-only query should return roughly the count you'd expect from Finder's own file count for that folder.

A meaningful gap usually means one of a few specific things: a subfolder outside images and video — PDFs, documents, project files — which the app doesn't read by design, since it's a tool for images and video and nothing else; a permissions issue on an external drive that resolves itself once the drive is properly mounted rather than merely connected; or a nested folder that got added to the source folder after the first pass already started, and simply hasn't been picked up by the watcher yet. Running the same check again after the pass settles usually closes any remaining gap, and it's worth doing this check once per root rather than assuming a clean result on one root means the others are equally clean.

Step 4: Carry across what a folder alone can't hold

Folders and file dates travel with the files themselves, so indexing catches them automatically. What doesn't travel that way is anything kept in another tool's own database — ratings, tags, notes — unless that tool wrote them into the file's own metadata rather than a separate library file. The one migration path built in here is a refern library: the importer matches files by relative path and carries across ratings, tags, notes and canvases without moving or rewriting the originals, which is what makes it safe to run even if you're not fully committed to switching yet — nothing is lost from the refern side by trying it.

Coming from somewhere else, the honest answer is that those labels stay in the other tool, and you re-apply what actually matters as you go rather than all at once. This is less painful than it sounds in practice, because most libraries only have a small fraction of their images carrying labels anyone would actually miss — the rest were never tagged consistently even in the old tool, which is often part of why a change felt worth making in the first place. It's worth resisting the urge to try to reconstruct every old label before considering the library "built" — that turns a one-afternoon task back into the open-ended project this whole approach is meant to avoid.

Step 5: Let the watcher take over from here

Once the roots are indexed, the ongoing work is nothing — the folder watcher turns filesystem events into the smallest re-scan needed to keep the database correct. A file added to "Studio shoots" next month is indexed without reopening anything, a rename in Finder stays a rename, and a folder moved to a different subfolder is followed rather than treated as a new, untagged file. This is the property that makes "building" the library a one-time task rather than an ongoing chore: after the first pass, keeping it current is a side effect of using your Mac normally rather than a separate job you have to remember to do.

The watcher keeps running after any trial period ends too, deliberately — an index that quietly stops updating is a worse outcome than one that was never built, because it looks current and isn't.

A worked example: three drives, one project

A common real shape: an internal drive with the last year of work, an external drive with three years of archive, and a third drive a collaborator hands over partway through a project with several thousand files nobody has looked through yet. Indexing all three as separate workspaces takes an afternoon of mostly-waiting rather than active work — register each root, let its first pass run, and move to the next one while it does.

By the end of that afternoon, a single query line can reach across all three at once, provided each root is currently connected: everything shot in the last quarter, above a certain resolution, across the internal drive and whichever external drives happen to be plugged in that day. The collaborator's handoff folder, previously just a folder nobody had time to sort, is searchable the same way the year-old archive is — by type, dimensions and date — without either one having been tagged yet. Tagging, if it happens at all, happens afterward and gradually, driven by what actually gets pulled into active work rather than as a prerequisite to using the library at all.

What happens to duplicates that already exist across folders

Building a library from folders that grew organically over years often surfaces the same image saved in two or three places — once in the original shoot folder, again in a "selects" folder, maybe a third time in something sent to a client. Indexing doesn't merge or deduplicate these automatically; it reads each file where it sits, so three copies of the same image remain three separate entries. That's a deliberate choice rather than an oversight — deciding which copy is the canonical one is a judgment call specific to your own workflow, not something safe to automate silently. Once the library is searchable, spotting these duplicates by eye is far easier than it was scattered across unindexed folders, even without a dedicated duplicate-finding step.

What a second pass looks like once the library exists

Building the library isn't a one-time event so much as a first pass that the watcher then continues indefinitely, but it's worth understanding what a deliberate second look accomplishes beyond what the watcher does automatically. If a root gets a large batch of new files dropped in all at once — a client hands over an entire season's shoot, say, rather than a trickle of individual files — the watcher still picks all of it up, but it's worth re-running the same sanity check from step three against the new total, since a bulk drop is exactly the situation where a partial copy or an interrupted transfer would otherwise go unnoticed until much later.

What to do when the library spans many drives

Nothing about the workflow changes; only the bookkeeping does. Keep a one-line note of which root lives on which drive, since a drive that isn't plugged in is simply not searchable until it's reconnected — the index for that root sits waiting rather than erroring, and reconnecting it reconciles what changed rather than starting over. Canvases can still reference images across several drives at once, because a .coii-canvas file just records what it points to; it's the images themselves that need their drive connected to actually display, the same way a shortcut needs its target to be reachable.

A library spread across drives is also a good moment to think about backup separately from search. Indexing makes a drive's contents findable; it doesn't make a second copy of anything, so whichever drives don't already have a backup plan still need one, and that's true whether or not the library is indexed at all — the two are entirely independent concerns that happen to get confused with each other often.

What a reference manager is built to do covers the fuller feature set once the library exists, and an image organizer that never touches the originals is worth reading if that property — one copy of every file, always — is specifically what you're building around. For the query side of things once everything's indexed, searching folders from one line picks up where this page leaves off. The price of doing this is worth checking too if that's part of the decision. Or start directly: thirty days, every feature, no account, and the roots you wrote down in step one are the only thing you need to have ready.