Dave Yost
| I propose a new file type for Mac OS X and other OSes that is at once an enhanced Mac OS X alias file and an enhanced symlink, solving the problems of both. An aliaslink can be used by unmodified BSD programs (alias files can’t), and an aliaslink follows a file or folder that moves (symlinks can’t). All alias files will be replaced by aliaslinks, and most symlinks will be replaced by aliaslinks, depending on how the symlinks are used. |
In this paper, I’ll use these terms:
read and write system calls
com.apple.ResourceFork extended attribute of a file
'alis') and that has an empty data fork
Sylinks first appeared in 1983, in 4.2BSD. BSD made the right choice for symlink resolution: the OS resolves symlinks during path lookup; an application must take special action to manipulate the symlink itself.
Alias files first appeared 8 years later in 1991 in Mac OS 7.0. Apple made the opposite design choice for alias file resolution: application or library code is responsible for calling special library functions to resolve aliases. While alias files are a wonderful thing, Apple’s design choice caused a lot of problems as application code had to do extra work to be compatible with alias files. Those problems are behind us for GUI apps, but Mac OS X, with its BSD base, has those old problems all over again when alias files are manipulated from a shell or other BSD program. BSD programs are not going to adapt. Nor should they. There is a better way.
Simplifying a little, an AliasRecord contains
To resolve an alias, library software first tries the relative path, then the absolute path, then if those are not found and the VolumeID matches, it tries to find a file with the FileID found in the alias record. If the volume is not mounted, the library software tries to mount it (if you want).
The data in an aliaslink is a superset of the data in a plain symlink. In addition to the usual plain symlink path data in the data fork, an aliaslink has an AliasRecord in its resource fork.
When the OS resolves an aliaslink, behavior depends on the existence of the referent of its symlink content:
When the AliasRecord of an aliaslink is resolved successfully by the OS,
When the symlink content of an aliaslink is modified directly, the AliasRecord is updated accordingly.
An aliaslink can be useful as an enhanced plain symlink, since it can reconnect to its referent after the referent is moved or unmounted (possibly causing the mounting of a local or remote volume).
An aliaslink is preferable to an alias file because resolution and updating are done at the low level of OS system calls (not in the CarbonLib level), so an application can open an aliaslink using a BSD system call, as if it were a real file or folder. By contrast, an alias file does not operate as expected for a shell user or BSD programmer; in that context an alias file simply opens as an empty file (its resource fork ignored).
The result of resolution of an aliaslink is never a symlink; rather it is the end result of recursively resolving symlinks until a nonsymlink is found, as is traditional with symlinks and with alias files on Mac OS and Mac OS X.
Plain symlinks are still allowed (alongside aliaslinks) because their behavior is still sometimes what you need: if the attempt to resolve a symlink fails, that is the end of it; moved items are not followed. This behavior is not possible with alias files or aliaslinks.
The BSD system calls that resolve symlinks work compatibly when applied to an aliaslink.
The BSD system calls that do not resolve symlinks but instead operate on the symlink itself work compatibly when applied to an aliaslink.
Mac OS X’s Alias Manager and File Manager routines work compatibly when applied to an aliaslink.
As of Mac OS X 10.4 (Tiger) all system-supplied programs that copy files have been enhanced to properly handle extended attributes. Other software will have to catch up.
Rather than an old-style AliasRecord in a resource fork, a new binary plist rendition stored in its own extended attribute should probably be used.
Perhaps an AliasRecord should stash information about intermediate symlinks along the way to the final destination, in case one of them stops working.
Aliaslinks will be superior to Windows shortcuts.
This proposal is in the spirit of Bruce Horn's original design for the use of data fork and resource fork: the data fork should contain the primary data of interest (for example, raw text), and the resource fork should contain annotation (for example font and style information).