If there’s one topic on which there is widespread misunderstanding, it’s the different ways that macOS has of providing links to files – in Finder aliases, symbolic and hard links, APFS clones, and macOS Bookmarks. This article does its best to make clear distinctions between them, so that you know both when and how to use them.

The most accessible are Finder aliases: select an item in the Finder, and with a quick Command-L you have got an alias which you can move anywhere to refer to the original file/folder. I’d be surprised if you don’t use them quite frequently.

In the Finder view above, you can see the normal icons shown for a text file and a folder in different forms. From the left, these are the original, a Finder alias, a hard link, and a symbolic link. This is confusing, as the Finder does not distinguish visibly between aliases and symbolic links. If you do use symbolic links, you may wish to make that distinction clear, because of the different effects of moving the original on the alias/link.

Hard links

Long before Apple invented Finder aliases, Unix got links in two varieties – symbolic and hard.

A hard link is a place marker to the actual file in the storage. Any reference to that place marker is automatically taken to the original file, as if it were the original itself. Ask for the size, permissions, or contents of the hard link and you will be given those for the original file itself. You cannot edit a hard link to point to a different file, and you can have several hard links which all point to the same file.

Because they are so efficient, hard links are ideal in Time Machine backups. Look in your latest backup and you will see that it appears to contain every file on your disk, although the great majority were not backed up recently. This is because most of what appear to be files are in fact hard links to the most recent original, which may actually be many backups ago. Every backup since then has just created another hard link which refers back to that original. Your backup volume may well include several million hard links: because they occupy almost no space at all and are so efficient, this is not a problem.

Time Machine backups not only rely on hard links to files, but they use hard links to folders too. In other versions of Unix, such directory hard links are often not permitted, even though folders are just another type of file. Currently, Time Machine’s reliance on directory hard links is one major factor which prevents you from backing up to APFS volumes, which don’t support directory hard links.

You can make hard links in Terminal’s command line using a command like
ln notes.txt noteshard.txt
which creates a hard link named noteshard.txt to the original notes.txt in the current folder. Finder doesn’t provide any means of creating hard links.

If you list the link using the command ls -la, it is shown as being identical to the original file, as macOS sees straight to that original via the link:
-rw-r--r--@ 2 hoakley staff 7298 28 Aug 18:10 noteshard.txt
The same happens in the Finder, which does not show the link as a separate object, but gives all the details for the original file.

Because Time Machine backups are complex assemblies of ‘real’ files and hard links, including directory hard links, if you tamper with them without knowing exactly what you are doing you can render those backups unusable. Apple strongly recommends using the Time Machine app itself or the tmutil command to maintain your backups, rather than manipulating them any more directly. [Changed following discussion below.]

Symbolic links

A symbolic link (symlink, or soft link) is quite different, as it is a tiny file which contains the directory path to the original file, making it a symbol for that file. Thus a symbolic link will only work so long as the original file remains in the same place, and keeps the same name. Change the name of the original, or move it to a different folder, and all symbolic links to that file will break.

Symbolic links can point to folders as well as files, and are effectively a “poor person’s alias”. For macOS users, they have limited application, as we tend to do terrible things like move folders around, only to discover that all the symbolic links inside have been broken. Their one potential benefit to a Mac user is that – so long as the file name and its path remain unchanged – the actual file or folder can change completely. Because a symbolic link consists of just a path and filename, it is also very economical in terms of storage space.

You can create symbolic links in Terminal’s command line using a command like
ln -s folder1 folder1symb
where the -s option creates a symbolic rather than hard link, folder1 is the original, and folder1symb is the link. Finder doesn’t provide any means of creating symbolic links.

If you list the link using the command ls -la, the link is shown as being a tiny file, and the link destination is indicated:
lrwxr-xr-x 1 hoakley staff 7 31 Aug 06:43 folder1symb -> folder1
lrwxr-xr-x 1 hoakley staff 9 31 Aug 06:44 notessymb.txt -> notes.txt

In the Finder, Get Info shows the link as an Alias (which is misleading, of course), and gives the path and name of the original to which it links. This all looks very similar to a Finder alias, except that its size is tiny, and there is no button to select a new original, as you cannot edit symbolic links in the Finder.

There are very few situations in which you are likely to want to use a symbolic link, but you may well come across them. For the great majority of everyday tasks on your Mac, the Finder alias is much preferred.

APFS clones

New with APFS in High Sierra is the clone: two (or more) apparently different files for which the file system points to the same data. At first sight, that might appear to be very similar to a hard link, but they behave completely differently when you attempt to change either of the clones.

With a file and a hard link, you actually open the original file, and change that. The link always points to that same file, and you are only changing one chunk of data, even though you can access it through the original file or its hard link.

Two clones are actually independent of one another. Edit one, and the other remains unaltered. APFS still sees them as being clones, but now they differ in part of their data. In these early versions of APFS, there are no indications that files are clones of one another, either in the Finder or at the command line. The only way to tell is that making a clone of a very large file is instantaneous – there is no copying of data.

Cloning occurs by default in High Sierra when working within a single APFS volume with Option-drag copying, and in Terminal using the -c option in the cp command. Neither the Finder nor Terminal show that a file is one part of a clone.

In theory, you shouldn’t need to know whether any given file is a clone or a true copy, but in practice this brings dangers for storage management. Imagine that you are getting a bit low in free space on a drive, and you’re working with a 50 GB movie, either as a straight clone or in a versioning system based on cloning. If you make some changes to it, they could amount to only a few megabytes of required disk space, or the whole clone could need to be written afresh, swallowing up most of 50 GB.

The Finder’s approach to this problem seems to be deliberately pessimistic, in assuming that each clone occupies the full space of the original. If you trust the Finder’s figures, you will therefore never use the space saved by this feature in APFS.

Finder aliases

These first appeared way back in 1991, in System 7 for classic Macs, so have had plenty of time to mature. They are also the only type of link which is fully usable from the Finder and graphical interface.

A Finder alias works on top of the file system using inode numbers, which are embedded in an opaque data structure and saved to a file, which forms the alias file. When you access a file or folder through an alias, macOS uses the data to work out where the original file or folder is. First it tries using the normal directory path, as if it were just a symbolic link; if that brings no joy, it turns to the inode numbers, which should remain unchanged no matter where file has been moved to on the same volume.

This makes aliases tolerant of moving the original file or folder, which is why they are so popular. The only snags with this are that their versatility comes at the cost of requiring more storage for the alias itself, and, being more complex, you would not wish to have millions of them on any given volume.

Finder aliases are easily made in the Finder using the Command-L shortcut, the contextual menu, or the command in the Finder’s File menu, but there isn’t (yet) a standard command tool to create them. You can always use an AppleScript, such as
tell application "Finder" to make new alias at (path to desktop folder) to file ((path to applications folder as text) & "Mail")
but that is ungainly and can readily go wrong.

Inspect them in the Finder, and you’ll be told that they’re aliases, but at the command line they’re just regular files of around 1 KB size:
-rw-r--r--@ 1 hoakley staff - 976 4 Dec 21:17 moreau alias
If you perform any actions on aliases at the command line, you will discover that they behave as if they were normal files, not links.

Prior to macOS Sierra, Finder aliases were more substantial in size, typically just under 1.3 MB. Now they contain a variant of macOS Bookmark data, which is more typically around 1 KB. Some software struggles to cope with this new format, though: at first, in Sierra 10.12 and 10.12.1, even the Finder wasn’t always sure what to make of them.

macOS Bookmarks

These are completely different from the most familiar bookmarks, URLs saved in a browser. Bookmarks have been used internally in macOS and applications since at least 10.9 Mavericks back in 2013. You will be most familiar with them in the Open Recent… command in the File menu of all the better macOS apps. They contain the same folder path and inode data as in a Finder alias, allowing apps to resolve file and folder locations even when they move or change other components within the path.

You’ll find them used throughout preferences and other files which store enduring references to files and folders. They are the basis of .sfl and .sfl2 SharedFileList files stored by Launch Services in the folder ~/Library/Application Support/com.apple.sharedfilelist.

Being chunks of opaque binary data, there is currently no access to them through the Finder or at the command line. From the Finder, their equivalent packaged into a convenient file format is the Finder alias. You can explore them using Precize and Preciziun, available from Downloads above.