Aliases, symbolic links, Path Finder aliases… Help!
April 30, 2007Today I want to write about something that confused me once and I was glad to find the explanation afterwards. I hope it will be useful for you as well. So here we go about the difference between aliases, symbolic links and Path Finder aliases.
Look similar...
Aliases and symbolic links (or symlinks) are "pointers" to a file or a folder which can be placed at a specific location while it is pointing to the "original" object at another location. You basically create a second representation of the object without having to create a copy.
Aliases are files that uniquely point to a specific file or directory, and continue to point to it regardless of where the file or directory (or the alias file itself) is moved or renamed. When an alias doesn't resolve, the system goes looking for it and asks you what it should do if it can't find it. Aliases are understood by the Finder, Path Finder and any other OS X program that implements the routines to resolve aliases.
Symbolic links are very similar to aliases, but symbolic links are lower level. They belong to the file system itself, and thus can be parsed by your terminal shell. Most Unix-level commands and utilities do not understand aliases, so it is necessary to use symbolic links if the file or folder will be accessed from a Unix-level program (e.g. Apache). Programs of higher level, like Finder or Path Finder have no problems to resolve symbolic links, so symlinks are understood throughout the whole system.
...but are different
An important difference between an alias and a symlink is that if the original file is moved or renamed and a file with the same name is put at the former place, an alias will still point to the previous version of the file, while a symbolic link will point to the new file at the same place. This behavior is useful e.g. when you need a reference to a file or a folder which is replaced in regular intervals by new versions, while the previous versions are archived. However a disadvantage of a symlink is that when it doesn't resolve it just goes broken. (it happens because symlinks are just files containing a string with the path to the file, whereas aliases store their information in resource fork thus containing more information about the original)
Both symbolic links and aliases are useful. Sometimes you want to point to a particular file or directory in a robust manner that will not break when things are moved or renamed (alias), but sometimes you simply want to point to "whatever file happens to be located at the following path..." (symlink). So the decision to use one or another depends on what you want to do with your original and what programs are supposed to access the link.
Although symbolic links are a core feature of Mac OS X, Finder is unable to create them. Also there is no easy way to distinguish an alias from a symbolic link in Finder. Both aliases and symbolic links appear in Finder with a little arrow in their icons. If you use "Get Info" in Finder on a symbolic link, it will show its kind as "Alias" - which is a bit misleading at least. Path Finder knows how to distinguish between symlinks and aliases, displaying their kind correctly and can also create them sparing you a trip to terminal.
Now what are Path Finder aliases?
Path Finder aliases are like regular aliases but that only Path Finder understands. They will always open the original in Path Finder regardless of the program you use to open them. They are actually just special files (with a hidden extension .path) that PF knows how to open, their kind is "Path Finder document".
What are they useful for?
Suppose you would like to have a folder in the Dock which would open in Path Finder. You can create a Path Finder alias (go to menu File -> Make Path Finder alias) of this folder and put it in the Dock - it will then always open in Path Finder instead of Finder. Handy, huh?
---------
Update: one of the commenters reminded me about hard links and I thought I'll complete my explanation although hard links are only rarely used on OS X.
Hard links - beasts from the past
Hard links act like "twins" in sync, you can't even tell which is the link and which is the original actually (Get Info on both files will show exactly same type of document, same size, etc). For example you change permissions on one file - and it automatically changes it on the other one, you can't even delete the file completely without deleting the other. On OS X Tiger it's not possible to make a hard link to a directory, only to a file (update: this is no longer true on Leopard, Time Machine uses hard links to folders), also your hard link should be located on the same partition of your drive as the original.
As far as I know, hard links are not always well supported by high level OS X apps, probably because in a certain way they are even lower level than symbolic links. If you allow me to go to really low level details, hard links are direct "pointers" to a unique identifier - a file system object called "inode" - which describes where all the pieces of a file are as well as various other attributes such as last access, modified and create times. When the file is written to the disk, blocks of data containing the file are given this unique identifier (inode) so that your filesystem knows that "file #000234" is the data starting at disk block #00FF and ending at ##0145. Now consider the following: aliases store the path *and* this unique identifier in their resource fork (thus knowing about the physical location of the original on disk regardless of it's path and vice a versa), symlinks store only the path to the file and hard links store only the unique identifier, thus all those differences in their behaviour. To add some history (and I'll stop there, it's getting terribly long now) - hard links have been around since the earliest days of Unix, symbolic links were invented by BSD engineers somewhat later and aliases come from OS Classic.
Posted by grotsasha at April 30, 2007 1:29 PMComments
Before posting the whole thing, I've done some tests to ensure that everything works as I describe. Now I've tried to move the original of an alias around once more, placing it to very different folders pretty much everywhere and it opened seamlessly each time. Maybe if several months pass the resource fork can also go broken somehow? No idea. Does it work for you immediately after you create and move it and stops working after several weeks? Does it ask you where's the original or does it just fail silently?
Excellent explanation. At the Unix level, there are both "hard" links (ln) and symbolic links (ln -s), but in general, symbolic links are created most often. Hard links are restricted to files on the same filesystem, but the link is independent of the filename.
Thanks for giving me a reason to use PathFinder aliases. I never understood why they existed.
Oh, you reminded me, I forgot about hard links. I posted an update above, so that everything is complete :)
Nice writeup. A case where hardlinks break in Mac OS X is atomic save. Atomic save is what most applications do, they don't just overwrite the file on save, but write out the file to a tmp file. After the temp file was saved error free, it is switched with the original. This prevents data corruption when something goes wrong while saving (e.g. power failure, or maye just some programm error, either the original or the new file are complete). This is usually done via a writeToFile:atomically:.
However if you do this with hardlinked files, then the connection to the other files is lost.
I believe that the alias works immediately after creating it and then moving the original file. When it fails, it prompts me with a dialog that includes a "Fix" button so that I can reselect the original.
It doesn't seem likely that the resource fork can just get broken after a while. My hypothesis is that after moving the original, the fact that it moved is cached in memory somewhere, but is not actually written to disk, so after a logout or reboot it gets broken.
IOW, I vaguely remember reading somewhere a long time ago that aliases in OS X are path based instead of file ID based like the aliases of old, and the Finder thus has to manually do some magic to keep the alias in sync with its target when it gets moved. But I could be just imagining or mis-remembering that.
The data stored in aliases is the same for both OS 9 and OS X, but the way they are interpreted is different. An alias contains both the path and the catalog node ID (for HFS disks at least) of the file it points to (among other things). In OS 9, when you resolve the alias, the ID is checked first, and if no file for that ID is found, it falls back to the path. But in OS X (I believe starting in Jaguar), the path is consulted first, and then the ID.
So, in OS X, if you move the file and then put a new one in the old location, then the next time the alias is resolved, it will resolve to the new file. If you just move the original file and don't put anything in its place, then the alias will follow the file to its new location. If an alias ever resolves to a different file or location, the Finder updates the alias with the path and ID of the file it now resolves to. At least that's what it's supposed to do, you never really know with the OS X Finder. :-\
One thing that might happen to break an alias has to do with the way some apps write out files. It's fairly common as a safety precaution, if you're overwriting a file that's already there, to first write the new data to a temp file, then once the entire file has been written out, swap it with the existing file and then delete the original. The newly written file will have a different ID, since it was newly created. If you then move that file, and then try to resolve an alias that pointed to the original, neither the path nor the ID will match and the alias won't resolve.
Thanks for this additional explanation. I was wondering why aliases break anyway, but couldn't imagine this situation where ID and path both break. I like when everything is clear, so thanks! :)
Great explanation -- as a unix geek and macos6++ user, I've long
wondered what the difference was between aliases and links / symbolic
links. Nice to know Alias == link + symbolic link. Also nice to
have the explanation for why they break in os x. Ah! It also
explains why when I update an application, the "link" to it in
DragThing continues to open the old file until I empty the trash, and
then it finds the new one.
One thing it might be worth adding in the discussion of (hard) links
is that the space dedicated to a file is only released when all the
hard links to it have been removed. That has an important
consequence: As Brian explained in his final note, many applications
replace a file by writing a new one and then renaming it -- replacing
the fileID in the "current path" with the fileId of the new file.
If there are multiple hardlinks to the original, only the one that
was used by the application (the "current path") will be changed.
The result is that there are now two files, the new one pointed to by
the current path, and the old one, still pointed to by the other hard
link(s). The disk space allocated to the old file will, therefore,
still be in use. Furthermore, which version of the file you get will
depend on the path you use.
As of OS X, are you sure that aliases still reliably point to the same file after the target file has been moved? I know this worked fine in classic Mac OS versions, but in my experience OS X aliases break all the damn time for no reason. These are always aliases where I've created the alias first by Cmd-Opt-drag, and then moved the original into a sub folder by category afterwards. Weeks or months later I'll try the alias only to have the Finder tell me that it can't find the original and I have to reassociate it manually. It got to the point where I contemplated writing an Applescript that would find all broken aliases and then search for non-alias files with the same names and automatically fix the broken aliases. But I never got around to it, and eventually changed my workflow to not use aliases any more, partially thanks to Spotlight in Tiger.