Apple file formats

From Helpful
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)
These are primarily notes
It won't be complete in any sense.
It exists to contain fragments of useful information.

Mac's double-forkedness

Macintosh files contain two forks, that is, two distinct streams if data:

  • Data fork: The main file data.
  • Resource fork: including metadata, icons, and more. Mostly a set of attribute/value pairs.


OSX tries to not much rely on this anymore, in that few things depend on the resource fork to work anymore.

But it's still present and working and various apps still need it.


MacOSX will usually add resource forks when it can, including in places like ZIP files (as separate files).

When it cannot, such as in email attachments, only the data fork is sent.


AppleDouble, AppleSingle

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

When both forks are accessed via the same filename, this can be referred to as AppleSingle. Apple's own filesystems did this, which applies up to OS9.


When Macs store files on the network, or on unix partitions, they often adopt AppleDouble, meaning that the resource fork is stored in a separate file alongside the first, with ._ (dot, underscore) prepended to its filename - for example, ._spectra.pdf contains the resource information for spectra.pdf.

This means non-Macs can read just the file's actual data (data fork) and avoid getting confused from the resource fork, while macs can additionally use the resource fork.


Notes:

  • On unices, AppleDouble resource files are automatically hidden, being dotfiles.
  • Files that do not really use the resource fork, the resource fork is quite small, often something on the order of 80 to 300 bytes.


See also

MacBinary

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Primarily combines the data+resource fork into a single file that does not rely on the filesystem; can be used to transfer such forked between systems via intermediate systems/transfer methods that have no idea about the forkedness.

Largely superceded by mac disk images (.dmg), and .zip files.

See also:


Zip

When you use MacOS' Create archive option on a folder, you get a regular zip, but it will also contain a __MACOSX directory that mirrors the data directory structure, and stores resource forks in AppleDouble style.


This will usually be transparent in Mac dealings with such ZIP files, but most other zip utilities in the world aren't specifically aware of Apple's added convention, so the __MACOSX directory will be unpacked on all OSes. It's useless on everything but Macs, and can be safely deleted.

Non-Mac StuffIt uncompressors are implicitly aware of the two forks (since they have actual status as such in the format) and will usually not uncompress on non-MacOS. You could say that StuffIt can be more convenient in that it will not create AppleDouble files.

BinHex

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Usually uses the .hqx extension.

Similar to MacBinary in function (combines the data and resource forks), but stores things in a larger, ASCII-safe (7-bit) format (similar to what Base64 does).

See also:


StuffIt

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Mac-specific compression format, that stores data+resource forks.

Since OSX doesn't really rely on the forks, there is now little need to choose this over more widely understood formats like .zip.

See also:

Apple Disk Image (.dmg)

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

The format is called UDIF, the extension .dmg.

Is mac-specific in that it has various optional mac-specific features, can contain HFS+ filesystems, can be password protected and, in recent versions, compressed.

Macs can open them, and also mount them as if they are a drive, which is often used as a convenient way to distribute software on OSX. (Similar in function to various CD image formats)

Windows utilities exist to extract files, convert it to ISO, and such.


See also:


.DS_Store

A binary file format that stores additional metadata, like colors, labels, icon positions, and window sizes.

You'll mostly see these files on Windows clients on mixed networks (as Finder hides it, as will other unices on account of the name starting with a period).


In OSX you can use scripting to access most of the information in this file.

File format doesn't seem to be documented(verify), but it has been described through observation / reverse engineering. If you want to parse, there are a few interesting resources, like:


See also: