Editing Resource fork (section)

== Compatibility ==
The complexity of programming with resource forks has led to compatibility problems when accessing other file systems via file sharing protocols such as [[Apple Filing Protocol|AFP]], [[Server Message Block|SMB]], [[Network File System|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#Microsoft|Alternate Data Streams]] (ADSes hereafter). macOS did not support storing resource forks in ADSes on SMB volumes by default until [[Mac OS X v10.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.<ref>{{cite web|url=http://support.apple.com/kb/HT4017 |title=Mac OS X v10.5, v10.6: About named streams on SMB-mounted NAS, Mac OS X, and Windows servers; "-36" or "-50" alerts may appear |website=Apple Support |access-date=2010-04-19 |url-status=live |archive-url=https://web.archive.org/web/20100724074659/http://support.apple.com/kb/HT4017 |archive-date= Jul 24, 2010 }}</ref>

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, macOS stores metadata and resource forks using a technique called [[AppleSingle and AppleDouble formats|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 macOS will handle storage of resource forks differently, depending on macOS 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 [[AppleSingle and AppleDouble formats|AppleDouble]] format to handle forks. If a fileserver supports both AFP and NFS, then clients using NFS will store files in [[AppleSingle and AppleDouble formats|AppleDouble]] format, whereas AFP users will stored the resource fork natively. In those cases, compatibility can sometimes be maintained by forcing clients to use, or not use, [[AppleSingle and AppleDouble formats|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 <code>SplitForks</code> and <code>FixupResourceForks</code> 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 <!-- see comment above about intentional space: -->'<code>snd </code>' or '<code>moov</code>', 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 [[endianness|big-endian]], the Resource Manager by itself does not have any knowledge of the contents of a generic resource, and so cannot perform the byte swapping automatically.)

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