Resource Fork - Compatibility Problems

Compatibility Problems

The complexity of programming with resource forks has led to compatibility problems when accessing other file systems via file sharing protocols such as AFP, SMB, NFS and FTP, when storing to non-HFS volumes, or when transmitting files to other systems in other ways (such as via email). The AFP protocol natively supports Resource Forks, and so resource forks are typically transmitted to these volumes as-is, and stored by the server transparently to clients. The SMB protocol supports a file metadata system similar to Macintosh forks known as Alternate Data Streams (ADSes hereafter). OS X did not support storing resource forks in ADSes on SMB volumes by default until OS X 10.6. In previous versions of the OS, including upgraded versions of 10.6, this feature can be enabled with a param change or by creating a special file.

Networked file sharing protocols such as NFSv3 and FTP do not have a concept of file metadata, and so there is no way to natively store resource forks. This is also true when writing to certain types of local file systems, including UFS, and on SMB volumes where Alternate Data Stream support is not enabled. In those cases, OS X stores metadata and resource forks using a technique called AppleDouble, in which the data fork is written as one file, and the resource fork and metadata are written as an entirely separate file preceded by a “._” naming convention. For example: ExampleFile.psd would contain the data fork, and ._ExampleFile.psd would contain the resource fork and metadata.

Compatibility problems can arise because OS X will handle storage of resource forks differently, depending on OS X version, settings, and file system type. For example, on an SMB network with a mixture of 10.5 and 10.6 clients. A freshly installed 10.6 client will look for and store resource forks on an SMB volume in ADSes, but the 10.5 client will (by default) ignore ADSes and use AppleDouble format to handle forks. If a fileserver supports both AFP and NFS, then clients using NFS will store files in AppleDouble format, whereas AFP users will use AppleSingle format (resource forks are stored natively). In those cases, compatibility can sometimes be maintained by forcing clients to use, or not use, AppleDouble format.

Many fileservers providing AFP support do not natively support resource forks on their local file systems. In those cases the forks may be stored in special ways, such as specially named files, special directories, or even Alternate Data Streams.

Another challenge is preserving resource forks when transmitting files using non-resource fork-aware applications or with certain transfer methods, including email and FTP. A number of file formats, such as MacBinary and BinHex, have been created to handle this. Command-line system tools SplitForks and FixupResourceForks allow manual flattening and merging of resource forks. In addition, a file server seeking to present file systems to Macintosh clients must accommodate the resource fork as well as the data fork of files; UNIX servers providing AFP support usually implement this with hidden directories.

Older applications written with the Carbon API have a potential issue when being ported to the current Intel Macs. While the Resource Manager and operating system know how to deserialize data correctly for common resources like “snd ” or “moov”, resources created using TMPL resources have to be byte swapped manually to ensure file interoperability between PPC and Intel-based versions of an application. (While the resource map and other implementation details are big endian, the Resource Manager by itself doesn't have any knowledge of the contents of a generic resource, and so cannot perform the byte swapping automatically.)

Until the advent of OS X v10.4, the standard UNIX command line utilities in OS X (such as cp and mv) did not respect resource forks. To copy files with resource forks, one had to use ditto or CpMac and MvMac.