Mac OS X aliases and symbolic links

Even though aliases and symbolic links may seem to be the same thing in Mac OS X, this is not completely true. One could think they are effectively the same because, with the switch to a Unix base in version 10.0, symbolic links became a “normal thing” in the system. However, for better or worse, differences still remain; let’s see them.

Symbolic links can only be created from the command line by using the ln(1) utility. Once created, the Finder will represent them as aliases (with a little arrow in their icon’s lower-left corner) and treat them as such. A symbolic link is stored on disk as a non-empty file which contains the full or relative path to the file it points to; then, the link’s inode is marked as special by activating its symbolic link flag. (This is how things work in UFS; I suspect HFS+ is similar, but cannot confirm it.)

Aliases, on the other hand, are created from the Finder (and possibly with SetFile(1), but I don’t know how) and are stored as regular, empty files if inspected from the command line. However, they have the a extended attribute set on them, which marks them as special files, and the necessary information is stored (I think) in their resource fork.

The interesting thing about aliases is that they are more versatile than symbolic links. For example: an alias can point to a file that is stored inside a disk image. When accessing such an alias, the system will automatically mount the corresponding disk image if not already mounted and then redirect you to the file. This may be interesting to transparently access files saved into an encrypted disk image: you store the files into the image, create aliases to them on your desktop and, when opened by any alias-aware application, the system will ask you for the image’s password, mount it and provide you the file. But, unfortunately, aliases do not work from the command line, so this benefit is not as impressive as it could be (at least for me).