Alter mid-level file system layer to read/write special metadata when getxattr() and setxattr() are called for com.apple.FinderInfo and com.apple.ResourceFork.
For com.apple.FinderInfo:
Apple's AFP client does not manipulate this extended attribute using FPGetExAttr/FPSetExAttr. Instead call appledouble_read() and appledouble_write() with flag AFP_META_FINDERINFO. This should perform the required functions (FPGetFileDirInfo/FPSetFileDirInfo) to set or retrieve the FinderInfo on a file. This can be implemented on all platforms since the size of FinderInfo is 32k and within the traditional size limits of extended attributes.
For com.apple.ResourceFork:
Apple's AFP client accesses this via traditional FPOpenFork/FPReadFork/FPWriteFork commands. Once again we can call appledouble_read() and appledouble_write() with flag AFP_META_RESOURCE. Since Darwin's getxattr() and setxattr() functions support setting an offset specifically for resource forks mostly mirroring the actual AFP fork calls, we pass that parameter to the lower level functions.
Once supported, afpfs-ng+MacFUSE should be able to achieve parity with Apple's native client on macOS with regards to platform specific metadata handling.
Side Note: Looking at the xnu vfs source, Apple's internal AppleDouble functions appear to work around the lack of truncate function for extended attributes by creating shadow files and re-writing the resized extended attributes in one pass, saving us the hassle.
Alter mid-level file system layer to read/write special metadata when
getxattr()andsetxattr()are called forcom.apple.FinderInfoandcom.apple.ResourceFork.For
com.apple.FinderInfo:Apple's AFP client does not manipulate this extended attribute using FPGetExAttr/FPSetExAttr. Instead call
appledouble_read()andappledouble_write()with flagAFP_META_FINDERINFO. This should perform the required functions (FPGetFileDirInfo/FPSetFileDirInfo) to set or retrieve the FinderInfo on a file. This can be implemented on all platforms since the size of FinderInfo is 32k and within the traditional size limits of extended attributes.For
com.apple.ResourceFork:Apple's AFP client accesses this via traditional FPOpenFork/FPReadFork/FPWriteFork commands. Once again we can call
appledouble_read()andappledouble_write()with flagAFP_META_RESOURCE. Since Darwin'sgetxattr()andsetxattr()functions support setting an offset specifically for resource forks mostly mirroring the actual AFP fork calls, we pass that parameter to the lower level functions.Once supported, afpfs-ng+MacFUSE should be able to achieve parity with Apple's native client on macOS with regards to platform specific metadata handling.
Side Note: Looking at the xnu vfs source, Apple's internal AppleDouble functions appear to work around the lack of truncate function for extended attributes by creating shadow files and re-writing the resized extended attributes in one pass, saving us the hassle.