External drive references show as missing when the drive name changes

A reference manager that stores the full path to each file — /Volumes/Archive/photos/portrait.jpg — works perfectly until that path is no longer valid. Unmount the drive and remount it with a different name, and every reference on that drive shows as missing. The files are still there, physically unchanged. The app simply cannot find them because it is looking at the old path.

This is one of the hidden costs of database-driven reference systems. They work seamlessly on internal storage where the drive never moves. Move those references to an external drive for collaboration or backup, and the paths become fragile. The problem gets worse if the drive ever needs to be renamed or if you use multiple Macs — each one might mount the drive with a different name.

Why external drive paths break

When you add a file to a reference manager, the app records the full path: type:file → path: /Volumes/ExternalDrive/references/photo.jpg. That path works as long as three things stay true: the drive is mounted, it mounts at the same name, and the folder structure does not change.

If any of those three things changes, the path becomes invalid. The reference app looks for the file at that path, finds nothing, and marks the file as missing or deleted. The file is still on the disk. The index is wrong.

This matters because external drives are common in reference workflows. You might use external storage to:

• Back up a reference library to a second physical drive
• Collaborate with a team by sharing a drive
• Organize references across multiple projects on separate drives
• Keep a growing archive on newer, larger drives as your library expands

Each time you move or rename a drive, or use it on a different Mac, the paths in a database-driven app become invalid.

What happens when you rebuild the index

Many apps have a "rebuild database" or "reindex" command. Running it rescans all the files the app can still find and rebuilds its internal structures. But it does not repair broken paths.

If your reference manager is looking for files at /Volumes/Archive and you renamed the drive to /Volumes/Archive-2, a rebuild will:

1. Scan /Volumes/Archive (which no longer exists).
2. Find nothing.
3. Mark those files as missing.
4. Rescans any files on other drives that are still mounted.

The broken entries stay broken. You either have to delete them manually and re-import the files from the new location, or live with a database full of missing files.

How external drives get renamed

There are many reasons a mounted drive might change its name or path:

• User renames it manually. You plug in an external drive called "Archive" and decide it should be "Archive-2025" instead. The path changes immediately.
• Mac names it sequentially. If you unmount a drive and remount it, or if multiple Macs mount the same drive, the system might name it "Drive" and then "Drive-2" and "Drive-3".
• Mounting at different places on different Macs. One Mac might mount an external drive at /Volumes/Backup while another mounts it at /Volumes/Backup-1.
• Time Machine or other software renames it. Some tools that work with external storage rename drives as part of their setup.
• The drive is used with a different filesystem or format. Switching between APFS and Mac OS Extended can cause naming inconsistencies across reboots.

None of these are errors on your part. They are all normal ways that external drives work. A reference system that cannot handle them is a system that leaks broken references as you grow.

The workaround: rebuild and re-import

To repair a reference library after external drives have moved, you typically:

1. Unmount the external drive.
2. Rebuild the index (which marks files as missing).
3. Remount the drive at its old name, or accept a new name.
4. Delete all the missing-file entries.
5. Re-import the folder from the drive.

This works, but it is destructive. Any metadata you created — ratings, tags, notes — is lost on the reimported files unless the app has a way to re-match them by checksum or other properties. Large libraries can take hours to re-import and may lose data in the process.

Why Coii Ref does not have this problem

Coii Ref does not store paths. When you point it at a folder — whether that folder is on internal storage, an external drive, or a networked folder — Coii Ref watches that location. If the folder is mounted, Coii Ref scans it. If it is not mounted, Coii Ref waits for it to remount at whatever path it mounts at next.

The key difference: Coii Ref is watching the folder you gave it, not the path. When the drive remounts with a new name, or when you move it to a different Mac, or when you rename it entirely, Coii Ref continues watching the same folder. The index stays current because the index is based on the folder contents, not stored paths.

This means you can:

• Unmount and remount external drives freely without breaking references.
• Rename drives without losing metadata.
• Move the same folder between Macs on a shared network without re-importing.
• Use the same reference folder on multiple devices without sync problems.

Setting up references on external drives properly

If you have a reference library that spans multiple external drives, the right approach depends on the tool you are using.

With a database-driven reference manager: Keep everything on internal storage if possible. If you need external drives, accept that moving them will require re-importing later. Avoid renaming them once they are in use. Keep detailed backups because re-importing can lose metadata.

With a folder-based reference system like Coii Ref: Point the app at each external drive as it is. The app handles unmounting and remounting automatically. You can rename drives, move them between Macs, or reorganize your storage without rebuilding anything.

For a growing reference library, external drive support is a real problem to solve. Many photographers and designers keep multiple terabytes of references across several large drives. A system that breaks every time a drive is unmounted is not practical at that scale.

The risk of database-driven external storage

The problem compounds when you use multiple external drives. A photographer with three portable drives of reference images — one for travel, one for backup, one for collaboration — ends up with a database full of broken paths if any drive gets renamed or if the naming convention changes between computers.

Database-driven apps store the full path because they need to know exactly where a file is. This works perfectly on a single internal drive. The moment you add external storage to the mix, you have introduced a point of failure. The app cannot simply re-scan; it has to remember the path was correct before and figure out why it is not correct now.

Some apps attempt to solve this with "auto-repair" features that try to relocate broken references by looking for files with the same name or checksum on other drives. This works sometimes but is fundamentally a workaround. You are still dependent on the app's heuristics for finding the file, and if the file has been renamed or moved into a different folder, the workaround fails.

Real-world complications with external drives

In practice, external drive paths break in ways you cannot anticipate:

• Drive mounting order matters. If you have two external drives and plug them in in different order, or at different times, one might get mounted as /Volumes/Archive and another time as /Volumes/Archive-1.
• Time Machine and backup software complicate things. Tools that back up or archive to external drives often rename them or create new partitions, leaving your reference app looking at a path that no longer exists.
• Collaborative workflows expose the problem. If you share a reference drive with a team, different team members may have it mounted at different paths on their Macs. A file accessible at /Volumes/Team-References on your computer might be at /Volumes/Shared Drive on a colleague's computer.
• Moving between Macs requires re-indexing. If you get a new Mac and move your reference drive to it, the path might be completely different. A database-driven app has to rebuild or re-import everything.

How folder-based indexing scales with storage

Coii Ref's approach — watching the folder, not the path — handles all of these scenarios automatically. The app does not care what the path is, only that the folder exists and is accessible. This matters because it means:

• You can rename drives freely. The app continues working.
• You can move drives between Macs. The app continues working.
• You can reorganize which files are on which drive. The app re-indexes them at their new location.
• You can backup your reference folders to multiple drives. The app watches all of them.
• You can use the same reference folder on a network. The app indexes it like any other folder.

This flexibility is especially valuable for professional workflows where external storage is the norm, not the exception. A designer with a 5 TB reference library cannot afford a system that breaks every time they connect a new drive.

Migration from other tools

If you have a reference library with broken external drive references in another app:

1. Locate all the missing files on their actual drives.
2. Gather them into folders, organizing by project or type as you prefer.
3. Point Coii Ref at those folders.
4. The app re-indexes all files and reads any metadata (EXIF, keywords, ratings) that was embedded in the files.

Metadata stored only in the other app's database — local ratings, notes, tags — does not transfer. But the files themselves are intact and searchable again. Going forward, Coii Ref watches those folders. If you move them between drives or Macs, it continues watching them without any manual rebuilding.

When external drive references matter most

External drive support becomes critical when:

• You have more than one terabyte of references. Most people store this on external drives because internal SSD costs become prohibitive.
• You use multiple Macs and want to sync a reference folder over a network or by moving a portable drive between computers.
• You back up your reference library to a second external drive and need both to be indexed together.
• You reorganize your storage — moving from an older, smaller drive to a new one — and do not want to break your reference system in the process.
• You work as part of a team and share reference drives where each person may have them mounted at different paths.

A reference manager that requires re-importing after a drive move is one that imposes a cost every time your storage needs change. That cost compounds over years of growing a large library. A system that watches folders instead of paths is a system that adapts to your storage layout rather than constraining it.

For photographers and designers working with large external reference libraries, folder-based indexing is the only approach that scales without constant maintenance. The 30-day trial at no cost lets you test your own setup with your own drives and see whether the difference matters to your workflow.

Read how to organize reference images on Mac for strategies that work with external storage at scale. The comparison with Eagle covers how different database-driven systems struggle with external drives compared to folder-based approaches. And image organizer that doesn't move your files explains the fundamental difference between database-driven and folder-based reference systems, including the external drive problem. For a practical guide to managing multiple external drives simultaneously, see reference organizer for photographers. If you're concerned about losing your library entirely when drives get renamed or moved, what happens to my library if the app shuts down shows why folder-based systems are safer. The section on does Eagle copy your files walks through how database systems lock you in through import, which compounds the external drive problem.