Fix Aliases Copied to New Drive

I restored a disk backup (that included aliases as well as files) to a new drive that (accidentally) has a different name. Now, all of the aliases on the new drive are broken because the /Volume name within each alias is not the name of the new drive.

How do I change the /Volume name within all the aliases on the new drive to the name of the new drive? (There are thousands of aliases that need to be fixed; it is not feasible to make the change in the usual, manual way.)

For example, suppose /Volume/Old contained the following:

/Volume/Old/file1
/Volume/Old/file1Alias
/Volume/Old/file2

I backed up the content of Old using Carbon Copy Cloner and restored it to a drive named New

/Volume/New/file1
/Volume/New/file1Alias
/Volume/New/file2

Unfortunately, /Volume/New/file1Alias is now broken because it still points to /Volume/Old/file1 whereas it needs to point to /Volume/New/file1 instead.

How do I change /Volume/Old/ ā†’ /Volume/New/ in all aliases on /Volume/New/?

A reddit thread suggests:

If the file paths are the same except for the name of the drive then rename the drive (it wonā€™t brake the ones that already work) make sure that they all work now, then you may change the name back if want.

Will this work? Is there a better way to fix thousands of broken aliases?

Thank you.

If you can just rename the new drive, thatā€™s what Iā€™d choose.

An alternate route could beā€¦
Set up an alias at /Volume/Old/ pointing to /Volumes/New/ (if the old drive is still at /Volumes/Old, rename it before you set up the alias). Your many file aliases will remain broken in the sense that their path will remain unchanged and still pointing at the old location, but with the new alias pointing to the new drive location, their paths should become revolvable again.

Yes, but will this actually work? In other words, will renaming the drive from New ā†’ Old both:

  1. Automatically change aliases that already refer to /Volume/New ā†’ /Volume/Old as well as
  2. Fix/reactivate the aliases that refer to/Volume/Old?

Iā€™m just nervous about breaking something else. And, itā€™s very curious to me that there are many questions on the web about fixing broken aliases after copying from one drive to another but I saw this very simple fix proposed only once and I canā€™t find any confirmations that it actually worked for anyone.

Thank you.

Iā€™d just go ahead and try. You can always revert the rename if it doesnā€™t do what you want.

As to #1: macOS aliases, unlike symlinks, will update on the fly when you change a folder/drive name on the aliasā€™ path. So if you already have /Volume/New aliases, they should automatically remap to /Volume/Old when you rename the drive New to Old.

#2: Yes.

I should start out by saying that I have two internal SSDs on this ancient iMac running macOS 12.7.2 Monterey:

  1. MacOS Contains the operating system, applications, and an emergency administratorā€™s Home directory; and
  2. MacUser (previously MacUsers): Contains my Home directory.

There is no third drive (/Volumes/Old), just the two internal drives listed above, one of which used to be /Volume/MacUsers and was (accidentally) named /Volume/MacUser (without the trailing letter ā€˜sā€™) when a failing hard drive was replaced with an SSD.

I presume that the idea of creating an alias named MacUsers that points to /Volume/MacUser is NOT an option since I have only two internal storage devices, right?

Iā€™d try exactly that. These are just aliases, regardless of what they point to or if a drive is internal or not. If you can set up an alias in /Volumes/ called MacUsers that points to MacUser you should be OK.

Alternatively, you can just rename the drive MacUser to MacUsers. This step is reversible.

1 Like

MacOS stores two key pieces of information related to the volume in an alias: its UUID (globally unique to each volume) and its name. When resolving an alias, it will first try to locate the volume with the stored UUID. If it canā€™t find this, it falls back to looking for a volume with the same name.

In your case, you have a new disk which will have a different UUID (in fact, simply reformatting the same drive will result in a different UUID) and youā€™ve named it differently. So resolving the aliases fails. The reason the method you found (renaming the volume to the old name) should work is this:

  1. You rename the volume to the old name, so the aliases can now resolve using the backup method of locating the volume by name.

  2. Aliases youā€™ve already updated with the new volume name will continue to work because they have the correct UUID stored in them.

  3. MacOS updates the information stored in the other aliases to reflect the new UUID (which it found by matching the volume name).

  4. Now all aliases have the proper UUID stored in them, so even if you change the volume name, the aliases will resolve.

What Iā€™m not sure about is when MacOS updates the information stored in the alias. It might be you need to try and follow the alias for it to be updated. I highly recommend you have a look at Howard Oakleyā€™s ā€˜Alifixā€™ utility which I think will sort out all your aliases once youā€™ve renamed the volume to the old name:

4 Likes

This post in Apple Community indicates that ā€œā€¦ you canā€™t make an alias at the same level as a volume ā€¦.ā€

I tried this work around using a Finder window of the computer, which lists all the Volumes:

  1. Cmd-Option-Drag /Volumes/MacUser to the Desktop;
  2. Rename the resulting alias MacUser (on the Desktop) to MacUsers; and
  3. Drag MacUsers back into the window of Volumes.

Releasing the alias, MacUsers, into the window brings up this warning:

And clicking on OK throws error code -8058:

I also tried using Howard Oakleyā€™s command line tool for creating an alias, alisma, but it also threw an error:

Argus-2:/ nello$ ls -l /Volumes
total 0
lrwxr-xr-x   1 root  wheel    1 Dec 27 16:49 MacOS -> /
drwxrwxr-x@ 16 root  admin  512 Dec  1 15:07 MacUser
Argus-2:/ nello$ alisma -a /Volumes/MacUser /Volumes/MacUsers
Error: couldn't create new alias.
-1
Argus-2:/ nello$ ls -l /Volumes
total 0
lrwxr-xr-x   1 root  wheel    1 Dec 27 16:49 MacOS -> /
drwxrwxr-x@ 16 root  admin  512 Dec  1 15:07 MacUser
Argus-2:/ nello$ 

So, my question is, how exactly can I create an alias at the root of /Volumes ?

(By the way, apparently creating a persistent symbolic link in /Volumes is not an option.)

I can create symlinks in /Volumes and they seem to work just fine. I need sudo though.

cd /Volumes
sudo ln -s ./path_to_new_disk name_of_old_disk

If it gets deleted on reboot, just add the sudo line to eg. ~/.bashrc. Obviously, then youā€™ll need to launch a shell and authenticate for sudo after reboot for the alias to show up again.

I created a symlink as you suggested.

Argus-2:Volumes nello$ ls -l
total 0
lrwxr-xr-x   1 root  wheel    1 Dec 27 16:49 MacOS -> /
drwxrwxr-x@ 16 root  admin  512 Dec  1 15:07 MacUser
lrwxr-xr-x   1 root  wheel   16 Jan  4 20:35 MacUsers -> /Volumes/MacUser
Argus-2:Volumes nello$

Now, some of the aliases reflect the current Volume name, i.e., /Volumes/MacUser as shown in Get Info:


Note that the Modification date is now today, presumably because in the process of the alias resolving the location of the Original file, it healed itself by updating either the new driveā€™s UUID or the target fileā€™s inode (or both).

But unfortunately most aliases are unaffected and Get Info reflects the old Volume name, i.e., /Volumes/MacUsers.

In summary, the symlink does NOT fix (all of) my aliases.

When my attempt to create an alias in /Volumes using alisma failed, I reported it to alismaā€™s developer, Howard Oakley, and he replied that it is not possible to create an alias in /Volumes due to ā€œpermissionsā€:

Nello Lucchesi wrote on 04/01/2024 23:58:

Iā€™m trying to create an alias to /Volumes/MacUser named MacUsers in /Volumes
using alisma but I get an error:

Argus-2:Volumes nello$ alisma -a /Volumes/MacUser /Volumes/MacUsers
Error: couldnā€™t create new alias.
-1

Is it not possible to create an alias in /Volumes ?

No - you donā€™t have the permissions to do so. Only the system can write files to /Volumes.

Very best regards,
Howard.

I donā€™t know what to say. I was able to create a symlink in there and confirmed it worked.

Yes, it is possible to create a symlink in /Volumes (although apparently a symlink there will NOT persistent after a reboot). Yes, a symlink fixes some aliases but not most of them (for me).

Howard is saying that it is NOT possible to create an alias in /Volumes.

UPDATE January 5, 2024 6:15 PM

I just tested the persistence of my symlink (MacUsers ā†’ MacUser) in /Volumes.

It was still there after logging out and back into my account. However, it was no longer there after shutting down, starting up, and logging back into my account.

Can you not restore the files again, this time naming the new drive properly?

Yes, thatā€™s an option that Iā€™ve considered.

But this erroneous restore occurred a month ago and Iā€™m hesitant be take this option because I was thinking that re-restoring would involve losing/overwriting all the changes that Iā€™ve made in the meantime.

Another option would be to write an AppleScript to repaire my broken aliases as discussed here and here.

And, finally, since almost all of my aliases were created by Hazel, the option that Iā€™ll probably take is to delete the broken aliases and let Hazel re-create them.

This seems like the best idea.

1 Like

Did you try creating the symlink, then running Howard Oakleyā€™s Alifix utility to ā€œrewriteā€ all your aliases?

Thank you for your suggestion.

The article announcing Alifix 1.0 says:

ā€¦ Towards the end of the El Capitan cycle, aliases had got quite wobbly, but early in Sierra, Apple revamped them and increased their reliability and usefulness. But no matter how conscientious you are, aliases have a habit of breaking over time.

When youā€™ve migrated folders from a series of old Macs, through a succession of versions of macOS, you may well end up with dozens which are either in danger of breaking, or already out of touch with whatever they pointed to. Unless you fancy spending long hours trawling through each folder, there doesnā€™t seem any practical way to check folders for stale or broken Finder Aliases ā€“ unless you fancy using my free utility Alifix.

Alifix version 1.0 is now available to scan through any selected folder, identify those aliases which are now broken, refresh those which are in danger of breaking, and tell you what your broken aliases used to point at, so you can trash or replace them.

This is ideal preparation for migrating to a new Mac, copying or cloning an existing disk, upgrading macOS, or as part of your periodic housekeeping routines.

The current product page says:

Scans folders deeply to identify and refresh all Finder Aliases, including those made by alisma. Reports all that are broken, and optionally writes adjacent text file with their internal details to help you repair the Alias.

While the symlink was in place, I did run Alifix on a folder of aliases, some of which had already been fixed by the symlink and the rest remained broken.

I found that simply scanning with Alifix had no effect on broken aliases.

I did NOT check the ā€œRewriteā€ checkbox when I ran it because I didnā€™t know exactly what it does. Based on the description in the announcement above, I thought that Rewrite would only ā€œrefresh those which are in danger of breaking,ā€ not fix broken aliases.

Have you used Alifix? Have you found that Alifix fixes broken links under any circumstances?

Alas, it looks like ā€œrewriteā€ doesnā€™t do what I thought it would. I think youā€™d have to write a script or something to extract the original path of each alias (which Alifix does do) and replace your old aliases with new aliases.