How to find a photo across several external drives

You are looking for one photo. You know the shoot, roughly the year, and exactly what it looked like. What you do not know is that the file is called DSC_4832.NEF and that it is on the third drive from the left. Searching by name was never going to work, because the name never meant anything.

The filename was never going to help you

Cameras name files with a counter. Nikon gives you DSC_4832.NEF, Canon gives you IMG_0114.CR3, Sony gives you DSC00291.ARW. The number rolls over every ten thousand frames, so the same name comes back around every couple of years, on a different card, in a different job.

That means a photo archive is the one kind of archive where name search cannot work. Every other search problem on a Mac assumes you can remember some part of what the file is called. Here the file is called nothing, and the counter is actively misleading, because several files across several drives will share it.

Folder structure carries the real information instead, which is why photographers build careful folder trees by date and client. That works until the archive outgrows the number of drives you can keep plugged in.

Why Spotlight cannot answer this one

Three separate reasons stack up here, and any one of them is enough.

The index lives on the drive. Spotlight keeps a separate index on each volume, so when you eject an archive disk, everything it knew about that disk leaves with it. A question about six drives means plugging in six drives.

Camera cards and many archive drives are exFAT. Spotlight does not index exFAT or FAT32 volumes at all, which covers most cards and most drives sold preformatted for Mac and Windows. We wrote about why Spotlight will not find files on an external drive in more detail.

The query you want to ask is not a text query. You want the frames from a particular week, or the ones shot on a particular body, or the ones that look like a harbour at dusk. None of that is a filename.

Search by what you actually remember

People do not remember filenames. They remember some combination of four things, and a catalog is useful exactly to the degree that it captures them.

• Roughly when. A season, a year, the job it belonged to.
• What it looked like. The single most reliable memory, and the hardest to type into a search box.
• How it was shot. Which body, which lens, wide open or stopped down.
• Where it was. The location, if the camera recorded one.

Every one of those lives in the file already. Cameras write it into EXIF at the moment of capture. The problem has never been that the information is missing. It is that the information is locked inside a file, on a drive, in a drawer.

Catalog the drive once, then keep the catalog

The approach that works is to separate the catalog from the drive. Read each drive once, store what you learned on the Mac, and let the drive go back on the shelf.

This is what GetFerret does. When it indexes a drive, it walks the media files at low priority and records three things against each one, keyed to that drive so they survive ejection.

A real thumbnail

A small JPEG preview is rendered and stored on your Mac, so you can look through a drive that is not plugged in and see the photographs rather than a list of counter names. Images go through ImageIO rather than QuickLook's thumbnail path, which matters because that is what gets you previews of RAW, HEIC and PNG files that would otherwise come back blank.

The capture facts

Camera body, lens, ISO, shutter speed, aperture, focal length, capture date, pixel dimensions, and GPS coordinates when the camera recorded them. For video and audio, the duration and frame rate. These are read once at index time and kept, so they are in front of you while the drive is in a drawer.

Automatic subject tags

Each image is classified on device using Apple's Vision framework, which produces scene and object tags such as beach, bicycle or dog. Those tags are searchable alongside any tags you add yourself. This runs locally and involves no network of any kind, which is the only acceptable arrangement for a client archive.

RAW is handled as a first class citizen throughout, not as an unknown extension. CR2, CR3, NEF, ARW, RAF, ORF, RW2, DNG and the rest of the major formats are all recognised as images.

Working through it in practice

Once the catalog is on the Mac rather than on the disks, the search becomes ordinary.

• Index every archive drive once. Plug each one in, let it read, put it back on the shelf. This is the only step that needs the drives.
• Narrow by the thing you are surest about. Usually the shoot folder or the year. Name and folder path are both searched, and matching is by substring, so a fragment from the middle of a folder name is enough.
• Then look, rather than read. Scan the stored thumbnails. Recognising a photo takes a fraction of a second and needs no vocabulary.
• Check the facts before you fetch. Confirm the body and the capture date on the candidate, so you go and get the right drive the first time.

The result you want from a photo archive is not really the file. It is the answer to which disk is it on, and that answer should not itself require the disk.

What this does not do

Being straight about the limits: a catalog stores metadata and a small preview, not your photographs. To edit or deliver a frame you still plug the drive in. This is a finding tool, not a backup, and it is not a replacement for a proper backup.

It is also not a photo editor or a library manager. If your entire archive already lives in one Lightroom catalog on one always connected drive, that catalog is already answering this question for you. The problem we are solving starts when the archive is spread across drives that spend most of their life unplugged, which is where most archives end up.