Making sense of AFP/SMB and resource forks on file shares
Almost two years ago I worked with a school district on a migration to Windows file servers from a competing platform. The most significant part of the project was the complexity of mixed workstation operating systems, OS9, OSX, and XP. As a result of that project I constructed the following table which I have since used as a reference.
From my own notes:
"Test results and research indicate Apple works with resource forks differently for each protocol. Mac file systems store additional information in files that other file systems, including NTFS, do not store. Apple deals with this by writing the extended data out to a separate “._” file when writing to other file systems over SMB, or by including the extended data in an alternate data stream within the file if written using AFP. This scenario results in the following regardless of what operating system is used to host the share: "
| AFP | SMB | |
| Windows (any version or utility) | Emulates AFP to share files with MacOS | Native file protocol, will copy files that contain alternate file stream (AFP) but will not automatically copy hidden files (OSX/SMB) |
| OS9 | Writes extended data using alternate data stream as part of same file, unable to read ._ files written by OSX using SMB | Unsupported |
| OSX | Writes extended data using alternate data stream as part of same file, unable to read ._ files written by OSX using SMB | Writes extended data in to a second hidden file starting with “._”, unable to read files with alternate data stream written by AFP. |
The results of our project was a conclusion that as long as the OS9 machines were going to be around, providing AFP access to the SMB file shares provided reduced complexity. The customer decided to work with a solution from GroupLogic that supported AFP 3.1 and clustering to host AFP shares on a Windows server, with a long term plan to move towards only SMB.