This week I’ve been mainly looking at Finder Aliases and Bookmarks, trying to get to grips with exactly what they are and how they work. This article wraps up what I have learned, with another visual summary. It also points out some interesting problems in QuickLook.

Under the generic heading of Bookmarks, there are three types of link which you’re likely to come across in macOS Mojave: the Finder Alias, which is a special file created by the Finder’s Make Alias command, Bookmark files which are made by my free command tool alisma, and stored Bookmarks which can be embedded in any file by macOS and apps.

Although Finder Aliases and Bookmark files appear and behave essentially the same, my reading of Apple’s documentation is that they are not quite identical. Bookmarks which are embedded in other files, such as those used by Launch Services, aren’t packaged up as standalone files, and differ to some degree in the data that they contain.

For the sake of simplicity, from here on this article will refer to Aliases, which includes Finder Aliases, Bookmark files and Bookmark data.

Aliases contain a rich set of data, both about the file/folder to which they link and other matters even including the size of the volume on which the original is stored. Key fields within that data give the full path components to locate the original item, and the inode number and other information which is specific to that item and more independent of its location.

The whole purpose of an Alias is to provide a robust link to its original file/folder, that is to resolve the Alias by returning a URL for the original. The Alias Resolver is a mature and hard-working part of macOS which doesn’t appear to write to the unified log. If you want resolver errors to appear there, you’ll need to handle that yourself.

The resolver is called frequently. Whenever anything wants to access an item which passes through an Alias, that Alias needs to be resolved. This includes the generation of QuickLook thumbnails and previews, which I consider below. This is significant to anyone using or exploring Aliases, as merely selecting an Alias in an Open File dialog, for example, will cause the Alias to be resolved.

The resolver first checks whether the path saved in the Alias results in a valid URL. If it does, then that is returned. There appears to be no further checking performed, such as matching the inode number saved in the Alias against that of the item at the path. This allows spoofing, in which the file pointed to by an Alias can be changed without breaking resolution of that Alias.

However, that needs to be performed with care to prevent the alias being resolved before the imposter is in place and correctly-named. If a user attempts this by dragging a file to the Trash, that is likely to result in resolution of the Alias before the imposter is fully ready, and the Alias will merely break rather than be spoofed. I have tried this, and it is quite tricky to pull off in the Finder.

If the resolver cannot obtain a valid URL from the stored path, it then uses other information, probably including the inode number, stored in the Alias, which is likely to generate a valid path provided that file is accessible on the same volume. If that works, the new URL is returned and the information in the Alias is then updated to point to the item’s new location. Note that, unless a Bookmark is written back to the document which contains it, only standalone Aliases and Bookmark files are updated in this way.

If the resolver is unable to generate a valid URL from the information in the Alias, it then returns an error. There are options to automatically invoke the standard dialog which offers to delete or fix the alias, or to pass the error back without any user interaction. Errors don’t result in any change to the internal data of Aliases.

Spoofing Aliases deliberately or accidentally can have strange effects, particularly with QuickLook, which give insight into how the Alias resolver and QuickLook caching can come into conflict.

In the Finder, QuickLook thumbnails are normally cached. If an Alias has already resulted in the generation of a thumbnail and preview which have been stored in the QuickLook cache, then those are apparently associated with the Alias itself. So when you successfully spoof an Alias by substituting another file for its original, QuickLook will still use the cached thumbnail and preview for that Alias.

QuickLook previews in other places, such as the Open File dialog, don’t appear to use the cache, though. At the same time that QuickLook was offering that thumbnail in the Finder, the preview offered in an Open File dialog was that for the imposter file which had replaced the original.

This may be related to the fact that when the resolver updates the contents of an Alias, that change isn’t readily detected by anything calling the resolver. There thus doesn’t appear to be a simple way for QuickLook to tell whether its cached data need to be refreshed because the item to which the Alias points has changed. It’s a subtlety which produces amusing demonstrations, but is of little importance to Mac users.

To round off this series exploring Aliases and Bookmarks, I expect to have one more version of Precize ready for release early next week, which will allow you to inspect the data in an Alias without resolving it, and to give finer control over resolution.