Native Resource Forks

[rofore]

Hi

I don't know if this has been discussed before, but I wonder if there is a possibility / feasible approach to use native HFS+/APFS resource forks on macOS-based servers for Netatalk 2.

Many thanks

[rdmark]

In theory, netatalk 2.x can already store resource forks as file system Extended Attributes, a behavior that is controlled with the ea option. In reality, I don't know how well this works on macOS, but it's worth some experimentation I think. You can inspect EAs on files on macOS with the xattr command.

ea:[none|auto|sys|ad]

Specify how Extended Attributes are stored. auto is the default.

auto

   Try sys (by setting an EA on the shared directory itself), fallback to ad. Requires a writeable volume for performing the test. options:ro overwrites auto with none. Use explicit ea:sys|ad for read-only volumes where appropriate.

sys

   Use filesystem Extended Attributes.

ad

   Use files in .AppleDouble directories.

none

   No Extended Attributes support.

https://netatalk.io/oldstable/htmldocs/AppleVolumes.default.5

[rofore]

Thanks! I must have missed that.. I now specified
/Users/testuser "Public Share" rwlist:@testuser rolist:nobody ea:sys
in AppleVolumes.default, but the resource forks still get stored inside a separate folder. I'll now dig into the code to see what happens..

[rdmark]

Right, this aligns with what I have observed as well. I wanted to hear your results before introducing bias. ^^;

3.x can certainly store resource forks as file system EA, so it must be either a bug in 2.x, missing implementation... or some arcane configuration detail that we're missing.

[NJRoadfan]

Coming back to this, Netatalk doesn't have the ability to store extended file data in a way that macOS understands it. The two most important bits are Finder Data (where things like filetype/creator, color labels, etc. are stored) and resource forks. Here is the summery of differences using Netatalk 3.0 and 4.0's options.

Finder Data:
Netatalk with appledouble = ea: Finder Data is stored in an AppleDouble formatted extended attribute called user.org.netatalk.Metadata alongside other Netatalk specific data.
macOS: Finder Data is stored in an extended attribute called com.apple.FinderInfo. Note that on HFS+ volumes, this is a "virtual" extended attribute as that file system can natively store Finder Data.

Resource Forks:
Netatalk with appledouble = ea: Resource forks are stored in an AppleDouble formatted "dot" file (ex: ._MyFile). An exception is Solaris where this can be stored in an EA called org.netatalk.ResourceFork.
macOS: Resource forks are stored in an extended attribute called com.apple.ResourceFork. Note that on HFS+ volumes, this is a "virtual" extended attribute as that file system can natively store forked files.

All other extended attributes created by macOS (ex: com.apple.quarantine) are stored as-is by Netatalk and are cross compatible.

Netatalk 2.x only realistically supports using .AppleDouble folders with AppleDouble formatted files holding all the above data.