Six drives, one search — but six separate workspaces underneath it

A reference library that's outgrown one internal drive doesn't stop being one library just because the files are now spread across an archive drive, a current-projects drive and whatever's plugged in for a shoot this week. The mistake worth avoiding early is treating that spread as a problem to solve by consolidating everything onto a single drive — for anyone with more footage and photography than one drive comfortably holds, that's usually not realistic, and it isn't necessary either. The actual answer is registering each drive on its own terms and letting search work across all of them at once.

This is also a case where the folder-based design of the app matters more than it might for a single-drive library. A tool that copies files into a managed library has to decide, once, where that library lives — and usually the answer is one drive, because moving a managed library between drives is its own project. Indexing folders where they already sit removes that decision entirely: a drive is just another folder to register, and how many of them exist is not a design constraint the app has an opinion about.

Step 1: Register each drive as its own workspace

Rather than trying to make one workspace span several drives, point the app at the top-level reference folder on each drive separately. Each becomes its own self-contained workspace, with its own database, thumbnails and proxies written inside that drive's folder — nothing about one workspace depends on another being present.

That independence is what makes the rest of this workflow forgiving. A drive can be reformatted, retired or replaced without any of the others needing to be touched, because nothing about how they're indexed ties them together beyond both being registered.

None of this requires deciding upfront exactly how many drives the library will eventually span. A workspace registered today doesn't need to know about a sixth drive that gets bought next year — each one is added when it exists, on its own terms, and the search behaviour described below extends to it automatically the moment it's registered, with nothing to reconfigure on the drives that came before it.

Step 2: Keep drive names stable once they're registered

A workspace is the folder you pointed the app at, which on an external drive includes the drive's own mount name as part of that path. Renaming a drive in Finder after registering it changes that path, which means the workspace needs to be pointed at the new location rather than continuing to resolve on its own. Settling on a naming convention before registering — Archive-2022, Current-Projects, whatever makes sense for how the drives get used — and leaving it alone afterward avoids that entirely.

Step 3: Search across everything, plugged in or not

The default behaviour of a query is to check every registered folder at once, without needing to specify which drive to look on. That matters most when a memory of where a file lives has faded — "the studio shoot from spring" might be on the current-projects drive or might have already been archived, and a query that spans both saves having to guess.

Results only come from drives that are actually connected at the moment the query runs. A file on an unplugged archive drive doesn't error or block the rest of the search; it simply isn't part of the result set until that drive is back.

That default is worth sitting with for a moment, because it's the opposite of how most people expect a multi-drive setup to behave. The instinct is to think of search as something that has to be pointed somewhere — this folder, this drive — the way Finder works. A query with no in: clause inverts that: it starts from everything and narrows only when told to, which is why leaving the scope off entirely is usually the right default rather than something to add "to be thorough."

Step 4: Scope a search to one drive when that's actually the goal

Sometimes the point is the opposite — checking what's specifically on the archive drive before deciding whether it's safe to reformat, say. The in: key narrows a query to one root without touching how the others are searched.

Step 5: Reconnecting is a reconciliation, not a rebuild

Plugging a drive back in after it's been offline doesn't trigger a full re-index. The watcher compares what it already knows about that workspace against what's actually on the drive now and reconciles the difference — files added while it was disconnected get picked up, anything removed is noticed, and everything untouched is left exactly as it was. A drive that sat unplugged for a month and came back with no changes reconnects almost instantly, because there's nothing to reconcile.

Step 6: Retiring a drive retires its workspace with it

Because a workspace's database, thumbnails and proxies all live inside the folder on that drive rather than somewhere central, retiring or reformatting a drive removes its workspace along with it — there's nothing left behind elsewhere to clean up. That also means the drive itself is the only copy of that workspace's index, which is a good reason to treat the drive's own backup as seriously as the files on it; the index rebuilds from the images if it's ever lost, but a backup of the whole drive avoids needing to.

Step 6b: What travel and rotation drives change

A drive that only comes home occasionally — one kept off-site for disaster recovery, or one that rotates with a second copy in a bag between a studio and a house — behaves exactly like any other registered workspace: absent from search while it's away, reconciled the moment it's plugged back in. There's no special "away mode" to switch it into beforehand and nothing to undo on return. That predictability is what makes an off-site rotation practical in the first place — the workspace doesn't need babysitting on either end of the rotation, just a plug-in when it's physically present.

Step 7: Check the first index pass actually caught everything

Before trusting a newly registered drive to a search, it's worth confirming the count of what got indexed roughly matches what's actually on it — the same sanity check worth running on any freshly built library, just applied per drive instead of once. A broad query with no filters beyond media type gives a total to compare against a rough Finder count.

A gap between the two is usually explained by file types the app doesn't read rather than anything actually missed — anything outside images and video won't appear in that count no matter how thoroughly the drive was indexed, which is worth ruling out before assuming a re-index is needed. One query line covering a whole folder tree is the same technique worth applying to any drive the moment it's plugged in for the first time, not just to catch a missed file but to get a feel for what's actually on a drive that hasn't been searched before.

Step 8: When a project's files live on more than one drive

A project that started on the current-projects drive and was partially archived off it — some files moved, some left behind — is a case worth naming directly, because it's common and because the tag-based approach to organizing references by project is exactly what makes it manageable. A project tag applied consistently finds every file that belongs to it regardless of which drive it currently sits on, which matters more here than almost anywhere else in a library — drives get reorganised, retired and replaced far more often than a project's own identity changes.

A worked example: four drives, one shoot spread across two of them

A studio with a current-projects SSD, a two-year-old archive drive, and a drive dedicated to raw video is a common shape once a library has been running for a while. A shoot that started on the current-projects drive and was later archived off it is exactly the case a spanning search is for —

— rather than checking each drive in turn and mentally merging the results. The tag doesn't care which drive the file physically sits on; it was applied to the file, and the file carries it wherever it ends up.

A second, quieter case worth walking through: the raw-video drive in that same studio fills up mid-project and a batch of footage gets moved onto a newly bought fifth drive, registered as its own workspace, while the rest of the project's clips stay put. Nothing about the project's tag needs to change for that split to work — the files that moved carry their tags with them, and a query for the project still returns all of it, footage on the original drive and footage on the new one together, with no step required to tell the app that a reorganisation happened. That's the practical payoff of tagging by project rather than relying on folder location alone: the files can move between drives for entirely unrelated reasons — running out of space, buying new hardware, reorganising a shelf of drives — without any of that housekeeping touching how the project itself gets searched.

Step 9: Decide how many drives is actually too many

There's a practical ceiling worth naming, even though the app itself has no opinion on drive count: search across every registered workspace happens at query time, which means a query touches every connected drive, not every registered one. A dozen archive drives that are almost never all plugged in simultaneously cost nothing extra to leave registered, since an unplugged one is simply skipped. What actually adds friction is remembering which drive holds what when there are enough of them that "the archive drive" stops being a single answer — at that point, a tagging convention that survives a file moving from one drive to another, covered above, matters more than trying to keep the drive count itself small.

Common mistakes worth avoiding

Consolidating everything onto one large drive "to make search simpler" is usually solving a problem that doesn't exist — search already spans every registered drive without that, and consolidation trades a manageable set of smaller, independently backed-up drives for one large single point of failure. Renaming a drive without re-pointing its workspace is the other common one, since the old path stops resolving the moment the name changes. And assuming an unplugged drive causes an error rather than simply being absent from results — it doesn't, and a workflow built around checking for an error message before searching is solving for something that was never going to happen.

What to do as the number of drives grows

A consistent labelling and folder-structure convention, decided once and applied to every new drive as it's added, is worth more at ten drives than any amount of cleverness applied after the fact. Tagging by project rather than relying on which physical drive a file happens to be on keeps search working the same way regardless of how the drives themselves get reorganised later — a project's tag doesn't change when its files move from the current-projects drive to the archive one, even though the workspace they belong to does.

Building a library from folders you already have covers registering the first workspace in more depth, and backing up a reference library properly is worth reading before trusting a single external drive with anything irreplaceable. What a proxy file is explains what actually gets written onto each drive during indexing, and an image organizer that doesn't move your files covers why registering a drive in place, rather than copying its contents somewhere else first, is the point. Or try it across your own drives — thirty days, every feature, no card and no account, is enough to register two or three and see whether one search line across all of them changes how the archive actually gets used.