Resolving Aliases

Resolving Aliases

When you’re working with an alias file, resolving it is easy. Just tell the Finder to get its original item property. Be sure to trap for error number -1728 in case it is no longer attached to its original item. “Orphaned” alias files are more common than you might imagine. And this additional nugget of wisdom might be important to somebody somewhere someday: the original item property resolves chained alias files all the way to the last original item. Thus, it never returns an intermediate alias file.

The more interesting task is to get the alias file itself when you want it. This tip offers several solutions.

First, AppleScript always attempts to resolve alias files before handing them off to a droplet’s open handler, so don’t look to a droplet to get yourself an alias file. Dropping an alias file on a droplet always passes to the script a reference to the original item, not a reference to the alias file. Like the original item property, it resolves chained alias files all the way to the original original item.

As a corollary, the Finder does not permit a disconnected alias file to be dropped on a droplet. The Finder used to present an error alert if the user tried. It’s smarter now: it doesn’t even highlight the droplet’s icon, so dropping a disconnected alias file on a droplet just leaves the alias file where you dropped it. Either way, the droplet is never even launched. Droplets therefore don’t even get an opportunity to explain the problem to the user.

Apple’s Choose File command used to behave similarly, in the days of the classic Mac OS. It always attempted to resolve alias files before returning, and it therefore returned a reference to the original item (or the original original item), not a reference to the alias file. Even today, the Choose File command refuses to permit a disconnected alias file to be chosen. It used to present an error alert if the user tried, but now a disconnected alias file is always dimmed in the dialog and can’t be selected. There is no way to detect that the user attempted to choose a disconnected alias file, so you get no opportunity to explain the problem to the user.

Today, however, in Mac OS X 10.4 (Tiger), when you use the Choose File command to choose a connected alias file, it does not resolve the alias file to its original item. Instead, it gives you an alias file to work with. I don’t know when its behavior changed in this regard. It seems to me that it must be a mistake, because if it is supposed to let you choose an alias file without resolving it, why would it refuse to let you choose a disconnected alias file? Nevertheless, it is now one more tool in the toolkit of any scripter who has a reason to work directly with an alias file instead of its original item.

There have always been two other ways to get an unresolved alias file into a script. The Finder’s selection property does not attempt to resolve alias files, and it therefore can return alias files”including disconnected alias files. Simlarly, of course, the Finder can just get an alias file, as can the System Events application, using any of the available reference forms, such as name or index. This, too, works even if the alias file is disconnected.

All of this begs the question of why anyone would ever want to get an alias file. I suppose you might want to know when it was created or last modified. In the old days, there was at least one third-party scripting addition (Jon’s Commands) that could give you useful information about an alias file, but it no longer offers this capability. I even wrote a script that allowed you to get some of the inner information from an alias file. These tools were potentially useful, because, for example, they let you get the path to an alias file’s original item even if it had become disconnected, so that you could make intelligent decisions about reconnecting it.