Main navigation

Aliases, links, clones, and Bookmarks

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 likeln 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 likeln -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.

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 astell 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.

16Comments

> “One snag with hard links is that all hard links to a file must be deleted before that file can be deleted. This is one good reason why you should never tamper with Time Machine backups yourself, but allow Time Machine to handle them: if you try trashing any given backup, you could be trying to trash the original files for tens of thousands of hard links, which need to be removed first. Time Machine should make a much better job than you can.”

A hard link is another entry in the disk’s directory that points to the same blocks as the original entry did. When a hard link is created, a counter somewhere is incremented. You can see this counter’s value in between the permissions and owner name when using `ls -l`. And you can indeed delete the original without fear. The counter will decrement, but only once the counter reaches 0, will the operating system declare that part of the disk as available for use again. It is entirely safe to delete a Time Machine snapshot.

You can see this illustrated with the following terminal commands (note the counter value seen between the permissions and owner):

I think that you’ll find the “counter somewhere” is actually in the inode data of the original file. If you delete that file without deleting the hard links to it, you are relying on a process in the file system identifying and removing all those hard links, or they will be orphaned.
Apple strongly recommends against using regular command tools to modify Time Machine backups, and provides additional tools which can modify them separately, such as tmutil. I have seen a lot of TM backups rendered unusable because users have not used tmutil, but gone in and deleted items themselves.
It’s your choice, and your data at risk.
Howard.

It’s also worth drawing attention to the fact that, if you put a backup in the Trash and try emptying it, that takes very much longer than emptying a similar number of files. This is probably because macOS is trying to delete all the hard links first, although this is not of course documented anywhere.
Howard.

I disagree re: trash delay. The time to delete the snapshot is simply because it has to “unlink” (aka delete) every file that was on your hard disk in that snapshot. Performing an `rm -rf /Volume` containing your OS and files would take the same length of time.

Why would Apple let the Finder let you delete snapshots? You can’t modify files, permissions, virtually ANYTHING inside the Backups.backupd using the Finder, or Terminal even as root!!! But they DO let you delete whole snapshots with the Finder. Do you think that’s been a bug in existence since TM’s inception?

Thank you – point made.
I have amended the text above to hopefully address these issues.
It’s also perhaps worth making clear that (I think) you are not referring to Mobile TM (and APFS) snapshots, which are quite different from regular TM backups.
Howard.

“You can use the Finder to move, copy, or delete the Backups.backupdb folder on your Time Machine backup disk as you would other folders. You can also delete folders within the Backups.backupdb folder. You can’t delete individual items inside the dated folders.”

No problems: I greatly welcome comments and discussions like this. I don’t always get it right – no one does. Not only that, but Apple’s advice has a habit of changing (usually just after I have written an article discussing it!).
Howard.

Howard Oakley wrote, “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.”

The very few can become the mighty where media collections exceed the size available on a macOS boot drive.

Side effect of moving terrabytes of media files to another drive can include faster Spotlight rescans and faster clone backups of the boot drive. But the “mighty” comes from transparent access to increased space without opening the computer to install a larger boot drive.

Thanks.
Why not use a Finder alias, though? If you decide to move the folder on that other drive, or rename any part of its path, then the symbolic link will be broken. With its fallback on inode numbers, so long as you don’t move them to another ‘file system’ (i.e. volume), the Finder alias should find them just fine.
When Finder aliases were 1 MB or so in size, a symbolic link would be far smaller. Now (since Sierra) that Finder aliases are based on Bookmarks and are only around 1 KB in size, I would have thought that they were a much better choice. And, for the ordinary user, they can be made and maintained in the Finder, not requiring the command line.
Howard.

To help, I have just got my next command tool running, which can create a Finder alias, and resolve a Finder alias to return the URL path to the original item. I need to do a bit more testing, and improve error reporting, but hope to make it available here in the next couple of days.
Then you’ll have an easy way of working with Finder aliases at the command line.
Howard.