Extended attributes on OS X allow applications to store additional metadata along data files. Filesystems like JHFS+ that natively support this feature store this metadata completely hidden from the user. On filesystems that don’t support extended attributes OS X writes this data into Dot Underscore (._) sidecar files. Many people including me have been bugged by this fallback and have searched for ways to remove those files. I described one possible way in my post Win & Mac: Clean Dot Underscore Files. However this post is about a very interesting problem that occurs only if you try to use a Linux server as a fileserver that exposes the same folder for OS X clients using SMB and AFP with extended attribute sharing.
The goal is that whatever network protocol you use you should always see the same data (including it’s metadata). To do that I disabled netatalk’s native EA support (ea = none in afpd.conf). Thereby SMB and AFP use the Dot Underscore fallback. In theory now all OS X clients independently of the network protocol they use should have a consistent view. However that’s only the theory.
If you write extended attributes using SMB and read the data over AFP it get’s scrambled. Here’s an example executed on a mounted SMB sharepoint:
$ xattr -w sh.bogner.test.entry 1234567890abcdef testfile #write EA $ xattr -l testfile #read EA sh.bogner.test.entry: 1234567890abcdef
Up to this point, everything is as expected: We could access the metadata and it was exactly what we put in. However, if you try to read the same metadata over an AFP-mounted sharepoint it’s a completely different picture: The metadata is completely unusable.
The problem I described here is an issue by itself, however some applications depend on working extended attributes. These applications either don’t work at all or have issues on such storages. Possible solution are to either go with separate EA stores for SMB and AFP, to delete all Dot Underscore files in close-to-realtime or to only use one protocol.