The problem

Did you ever want to install a font on your Mac that’s on a SMB share, for example on a Windows/Unix server? Did you experience the font was broken somehow, being displayed in the finder as “unix executable file” with 0kb size?

We had this issue here often, finally I figured out why this happens.

Behind the scenes

When you come from the Windows world, you’ll know that a filetype is determined by the file extension. A Word document is only recognised as such when it has the extension .doc (or .docx). When you change this to something else, or completely remove the extension, Windows has no idea what kind of file it is and thus with which program to open it. One could say this is a stupid way to handle it – why not have the file type stored as meta information inside the file itself, so there’s no risk that users kinda destroy their files by accidentally changing their extension.

On Macs, this is handled differently. There is meta information, this must be stored somewhere in the Mac file system HFS(+), NOT in the file itself. This leads to problems, because this is one of many “we’re Apple, we’re doing it completely different than the rest of the world, so we’re incompatible to the rest of the world” things.

Analysing the problem

So, on a Mac, “regular” data is stored in the file itself, called data fork, but metadata (like embedded images, icons, image preview thumbnails, …) is stored in the so-called resource fork. This is done, as mentioned, in some place related to the file system.

Now other file systems do not support these resource forks, so that they would get lost if you copy a file from a mac to a different FS. A Mac solves this as it splits the resource fork into a second file, which has the name of the actual file, prefixed by dot underscore (._). So if your file is called tree.jpg and you copy it to a SMB share for example, a second file will be created there called ._tree.jpg.

Normal users won’t see these because files prefixed with a dot are hidden by default. Anyway, if you have “show hidden files” enabled or do “ls -la” on a UNIX-based system, you can see them.

Now when you copy this jpg back to a Mac, it seems to be clever enough to look for a corresponding resource fork file, copy that one over as well and then automagically merge both (or rather store the metadata from the ._-file in the HFS file system again). So usually, copying stuff from or to a SMB share or some other volume with non-Mac file system should work flawlessly. Unless you delete the ._-files on that volume – this breaks some files which have important data in the resource fork.

Mac fonts apparently store all their data in the resource fork; their data fork is empty. Example:

On your desktop, you have font called MyFontBold – the finder says it’s 40kb in size and it’s a PostScript Type 1 Outline Font. Now open a terminal and do a ls -la on the desktop, you’ll see this:

-rwxrwxrwx 1 youruser youruser       0   Mar 14 2009   MyFontBold

indicating that the actual file has 0kb in size. Now copy this file to a different file system, for example on a UNIX server. The finder again lists the font with the correct size and icon, but in the terminal you’ll see this:

-rwxrwxrwx 1 youruser youruser   40172   Feb  3 2010   ._MyFontBold
-rwxrwxrwx 1 youruser youruser       0   Mar 14 2009   MyFontBold

Now you can see that the actual data of the font is stored completely in the resource fork because the newly created file (look at the timestamp) apparently has some content due to its file size, while the original font file is still empty (0kb). And now it’s clearly understandable that, when you remove the resource fork file, the Mac can’t do anything with the data fork file – the font is irreparably broken. However, this is only possible on non-Mac file systems, because the relevant data from the resource fork is stored in the file system itself on Mac file systems and thus cannot be deleted by accident.

The solution

What can you do to avoid this?

• Stick to the same kind of mounting shares. When you copy a font to a SMB mounted volume and read it via SMB as well, it works fine. Same with AFP. Just don’t mix it up: Storing a font via AFP and then reading via SMB corrupts the file.
• Convert your PS Type 1 fonts to OTF (OpenType format). This format does not use the resource fork, so the problem cannot occur at all – all the font data is stored in the data fork (in the file).

This article also deals with this problem.