If ever there was a term used in current versions of macOS which harked back to the days of Classic Mac OS, it is Finder Info.

In my quest to document the extended attributes (xattrs) found in and used by macOS Sierra and High Sierra, I have just posted a couple of articles detailing com.apple.FinderInfo and com.apple.LaunchServices.OpenWith. The origins of those go back to the very first Macs.

One of the central design principles of the Mac human interface was that a user should be able to open a document merely by actions on the document alone, such as double-clicking its icon. That brought with it several requirements, including the association of different types of file with different desktop icons, and the association of different types of document with the apps which should open them.

Apple’s solution was to assign two four-character codes to each file. The first designated the file’s type, and the second its creator, the app which could open it. Apps were given the type APPL, for application not Apple, for example. Together, these pairs of four-character codes were known as the Finder Info.

Classic Mac OS then maintained a hidden Desktop Database, which mapped all the types and creator codes, and their associated icons. There were default icons, for files which had the codes ???? and ????, or whose associations or icon were not known to the Finder. This was one of the many bits of magic which formed the illusion of the original Mac Desktop and Finder.

When Mac OS X came along, it brought that approach into collision with Unix philosophy, which said, for example, that all text documents have the extension .txt or .text. So in the early versions of OS X, both schemes had to be supported, whilst future policy was agreed. Some wanted the Unix approach to prevail, but what we have ended up with remains a unique blend of both.

Even in High Sierra, ancient Finder Info lives on in the first eight bytes of xattrs of the type com.apple.FinderInfo, which can be attached to files and folders as necessary. New Finder Info codes have been added, such as a type of alis and creator MACS to indicate an alias, something that didn’t exist in the original releases of Classic Mac OS.

The Desktop Database, which every so often used to get corrupted and had to be rebuilt, has been replaced with the Launch Services database, which I have examined in detail in this article. Among its many tasks are maintaining the associations between document types and apps, and all files and their icons shown in the Finder. Corruption in the Launch Services database is very unusual, and there is no longer a convenient trick the user can pull to fix such problems.

macOS has also introduced convenient ways to change the default associations between document types and the apps which open them, including the ability to make an individual document behave exceptionally: this relies on a xattr of type com.apple.LaunchServices.OpenWith being attached to the document, which specifies exactly which app Launch Services should make the default for that document alone. You can set those in the Finder’s Get Info dialog, of course.

I don’t know how much notice Sierra and High Sierra now take of those two four-character codes at the front of the com.apple.FinderInfo extended attribute. They remain, though, as a reminder of the long history of the illusion created by the Finder.