Macs used to be the only computers that did not need filename extensions; now they have conformed, but iOS lacks them. Why?

To any computer, even devices that contain computers but present themselves to consumers as smartphones or tablets, files are just discrete storage units, and folders just containers for files.

However when you tap or double-click on the icon representing a file or folder, you expect the computer to know what you want to do. In the case of an application, it should start up; a document should be opened by the default app set to handle that type of document; a folder should open and reveal its contents.

Classic conventions

On a Classic Mac running Mac OS 9, your double-click is passed to the Finder, which then looks in its hidden database to see what type of object you have tried to open. Every file has there two four-character codes giving the file type and its creator. In the case of applications, they have the type APPL, so the Finder knows to start them; in the case of a document, the Finder tries to start the application indicated as being the document’s creator.

These Finder metadata are moved around in a special storage area associated with every file in the Macintosh Extended (HFS+) volume format, its resource fork. Lesser file systems (and operating systems) view files as consisting of just a single glob of data; HFS+, ‘classic’ Mac OS, and OS X all allow each file to have two (or more) forks.

The first, the same as that basic glob of data on other file systems, is the data fork; the second, almost unique to the Mac, is the resource fork, and consists of structured information including the Finder metadata that set the file type and creator. So on classic Mac systems, you can name applications, documents, and most other files almost anything that you like, as the name is not linked in any way to the type of thing that file is.

The transition to OS X

When Apple was developing the first release of OS X, many of its engineers did not come from a Mac background, but were Unix wizards, brought up in the tradition that filename extensions indicated what a file is: .text or .txt indicates a generic text document, .config or .cfg a special text-format Unix configuration file, and so on.

The hybrid operating system that became OS X had thus to please two different philosophical stances, two opposed schools of thought. The perfect compromise was to support both approaches, Mac and Unix. However over the years those dyed-in-the-wool Mac engineers have become fewer in number, and OS X has steadily become more insistent on the use of correct filename extensions.

Apple has kept the magic in the Finder, maintaining its illusion even though the interface has changed so much. Whereas classic Mac applications stored a lot of ancillary information, such as localised versions of its menus and dialog contents, icons, and other paraphernalia, in the resource fork, OS X applications have to do this within a folder, that looks like an application. This trick, of disguising folders as single file-like objects, extends to several other special items, such as installer packages, and other bundles.

The present

Thus OS X has inexorably moved away from using the resource fork, despite HFS+ still supporting them.

This has significant benefits, as resource forks are notoriously non-standard. Copy a file with a resource fork onto a disk formatted using an MS-DOS FAT format, such as a memory stick, and the contents of the resource fork have to be moved into a hidden file which is often left out of subsequent transfers, breaking an application, for instance. Similar effects happen if you compress the forked file using a popular cross-platform tool that is not aware of resource forks.

OS X does still keep hidden files that indicate which applications can open which types of document, and which should as a default. You can see these at work when you select a document and Control-click (or secondary-click) to bring up the Finder’s contextual menu. At the top it will offer to open the document using its default application, below that listing other applications that are designated as being capable of opening this document type, including a link to the App Store to look for further possibilities.

Alternatively select the document and use the Finder’s Get Info command to show a dialog including the Open With section listing the application set to open that document by default. This is the normal way in which you can change that default, either for that document alone or for all of its type, by changing the application set and then clicking on the Change All… button.

RCDefaultApp is a free System Preferences pane from Rubicode (last released almost six years ago, but still working under Yosemite!) which gives you more direct control over these settings: its Apps tab lists all the applications that it can find on your Mac, and for each shows the file extensions that app can open; the Extensions tab lets you set default applications for each file extension; its File Types tab does the same across the Mac OS classical file types, which are still supported in Lion.

It also gives similarly powerful controls over URLs, UTIs, and MIME types. Other more general utilities can open up access to these settings, but despite its age RCDefaultApp remains the most complete.

In your normal work, you may find all these extensions get in the way or irritate you, in which case you can turn them off in the Finder’s Preferences, under the Advanced tool. However if you show all filename extensions you should get better insight into how they work to keep order in many important folders.

Take a glance at some of the essential components that work within OS X: in /System/Library/Extensions, for instance, you will find software extensions to the kernel to support different hardware devices, all duly accorded the extension of .kext, for ‘kernel extension’ and commonly known as KEXTs. .plist files are XML Property Lists, containing settings, preferences, and the like, and are found in many Library folders. They also feature in the LaunchAgents and LaunchDaemons folders, containing specifications of those components that are started up automatically, under the control of launchd.

Exceptions

The greatest anomaly in the use of filename extensions is in files consisting of executable code, such as command shell tools. Shell scripts normally have the extension .sh if they are to be run in a command shell, such as in the Terminal application, but are editable text files.

All executable code files, including background services, command tools, and even the code contained within applications, are named without any extension. This is to conform with standard Unix practice, rather than the Windows tradition of .exe and .com.

For traditional Mac users who had come to love freedom from the mechanical discipline of file naming conventions, the rise of filename extensions may seem to be a sell-out to the Unix and Windows world. In fact these extensions enrich and enhance, and should only very seldom trip you up once you understand their whys and wherefores.

They are essential to maintaining the wonderful illusions worked by the Finder and OS X, and keeping your work productive.

Technology: Inside a .app

An application with the .app extension looks in the Finder to be a single object with its custom icon for identification.

In fact what you see is pure illusion created by the Finder, for it is really a folder containing a fairly rigorous structure of sub-folders and files with different functions. Select the application icon in a Finder window and Control-click (or secondary-click) to bring up the Finder’s contextual menu, within which use the Show Package Contents command to open it as a folder.

At the top level, all applications – folders with the extension .app – contain a single wrapper folder named Contents.

Within that you will see an array of folders and documents that make the application up. The executable code, one of the few files that does not have an extension, is tucked away inside the folder named MacOS.

The Resources folder contains those files that in Mac OS Classic would have been stored as resources, in the resource fork of the application file. In that are graphics and icon files for all the icons and other visual devices used by the application, text, html and other content used by various windows, and .nib documents created by Xcode’s Interface Builder; the latter are packaged folders and can be opened further using the Finder’s contextual menu.

Applications with multi-lingual support will usually have separate .lproj folders containing localised resources for each different language version, and you could produce your own custom localised version by adding such resources. Help files, DTDs, templates, and defaults may also be kept here.

At the top level, Info.plist is a mandatory XML property list containing essential settings, including a listing of the document types handled by the application. PkgInfo holds the old Finder information, and the _CodeSignature folder contains the signature which is verified by Gatekeeper when you first run an app downloaded from the Internet.

Technology: Installer Packages

Applications are not the only specialised folder types that the Finder pretends are single objects: another common subject for this trick is the Installer Package bearing the extension .pkg.

Commonly delivered in Disk Image .dmg files, which are a single file designed to survive transmission over the Internet, packages are another folder bundle with a standard prescribed layout and contents. However some packages are now supplied as compressed archives which cannot be opened directly in the Finder without decompression.

Packages can be inspected using the Installer’s Show Files… command in its File menu before you install the contents, but Installer lets you do little other than install or sometimes uninstall each package. Further details of how the Installer and packages work are here.

Like an .app, an Installer Package has a single wrapper folder named Contents, within which are two property lists, Info.plist and version.plist, the former containing the important settings for the package.

The items to be installed are supplied in Archive.pax.gz or similar, a compressed archive which has the same folder structure in which they will be installed on your Mac. Archive.bom is a ‘bill of materials’ listing of the contents, which will be placed in the boms folder in /Library/Receipts, and form the material used for checking/repairing preferences. The Resources folder contains all the tools and scripts needed to run the installation within the Installer application.

Updated from the original, which was first published in MacUser volume 28 issue 10, 2012.