Aliases, Hard Links, Symlinks, and Copies in Mojave’s APFS
There are now five different types of copy/clone/alias/link: the regular copy, APFS clone (copy on write clone), symbolic link (symlink), hard link, and Finder alias. I’ll tackle them in that order.
Bookmarks are a generalisation of Aliases which allow variants, including those saved as files, both the Finder Alias and
alisma’s Bookmarks, which are similar but not identical. Bookmarks have been used extensively internally in macOS and applications since at least Mavericks 10.9 in 2013. They’re now used in a lot of preference files and other places, particularly by Launch Services in its SharedFileList files stored in ~/Library/Application Support/com.apple.sharedfilelist.[…]
The remaining issue with Bookmarks and Aliases is that they cannot ordinarily be resolved at the command line or in scripts. My free tool
alismashould be a help, as it can return the absolute path from a Bookmark file or Alias.
Here are a couple of tables which summarise the most important features of different types of copies, clones, links and aliases used in Mojave running on APFS (with a little reference to HFS+ too).
The bug occurs if you select a Finder Alias to a missing folder in a window set in Column view. After an initial pause of a few seconds, the spinning beachball appears, and the only way to regain access to the Finder is to press Command-Option-Escape, then select Finder and restart it.
One of the claimed advantages of Finder Aliases, and their parent Bookmarks, is their robustness in the face of change. Because they can use both an absolute path and the unique inode number to resolve the location of the item to which they point, they should be much more reliable than symbolic links, and easier to use than hard links. Indeed, since System 7 in 1991, they have been the only form of link which can be created in the GUI of Mac OS and macOS, the others requiring command line access.
[…]
When studying the contents of orphaned Finder Aliases and Bookmarks, whose original items had been removed, I noticed that some contained paths not to the original location of the item, but to it after it had been placed in the Trash, but others had retained the original location instead. A little further experimentation confirmed an interesting aspect of their behaviour: resolving an Alias or Bookmark will cause its saved paths to be updated if they have changed.
[…]
Given the information stored in an Alias about the file or folder to which it points, this is perhaps not surprising: the resolver has a lot more to work with than just the path, volume and inode number, and does appear to use that additional information to ensure that, most of the time, the link between the alias and original will work, and it won’t be fobbed off by another item posing as the original.
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.
The new features in this version of Precize which make this possible include separating the analysis of Alias contents from resolving them. There’s also a checkbox to avoid changing the Alias data when resolving it: although this shouldn’t make any difference, as it is working on extracted data from the Alias and not the Alias itself, I offer it as an option.
Previously: BookmarkData Exposed.
Update (2019-01-23): Howard Oakley:
At the instigation of Thomas Tempelmann, I now offer you a free tool to check and refresh your Finder Aliases: Alifix. Those which it finds are now broken beyond automatic repair it lists, and if you want it will save an adjacent text file in which all the internal data from the Alias is decoded and displayed, so you can decide what to do with it.
The only totally reliable method which I have discovered for forcing the Alias data to be updated is to resolve it into fresh Bookmark data, then write that Bookmark out as new data to the original Alias file, using the sequence
let theNewBMData = try URL.bookmarkData(options: [URL.BookmarkCreationOptions.suitableForBookmarkFile], includingResourceValuesForKeys: nil, relativeTo: nil) try URL.writeBookmarkData(theNewBMData, to:)
2 Comments RSS · Twitter
BTW: Long ago I wrote a tool for myself that would find all Alias files and update them, in order to make sure that both their path and their recoded file ID match. That's important when you plan to clone your entire disk to another volume via file-copy (vs. block-copy), because the clone's file IDs will be different. Without updating your aliases before this step (and another run afterwards, to be on the safe side), you may find that some Aliases will be broken.
I had repeatedly considered releasing this as a tool to the public, but I was afraid that it would cause me more grief, having to explain the details to users than it will help. Instead, I wished that file copiers such as CCC would do (or offer) this on their own, but they don't, or do they?
