(re)introduce macOS style metadata sidecar option

[rdmark]

while refactoring away the appledouble option in afp.conf between v4.1 and v4.2, we lost the ability to configure netatalk to always store metadata in macOS style sidecars (._ prefixed sidecars in the same dir)

up until v4.1 you could get macOS style sidecars through this (arguably confusing) combination:

[Global]
appledouble = ea
ea = ad

I suggest we bring back this option in the unary style:

[Global]
ea = macos

[rdmark]

...or shall we call it ea = darwin to emphasize the FLOSS core OS roots?

[NJRoadfan]

I'm a bit confused as to what the issue is here. The ea option controlled how client extended attributes are stored (ea = ad only really exists for OSes that don't support native EAs), while the appledouble option controlled how the resource fork, finder info, and netatalk metadata are stored (._ files+a metadata EA, vs the .AppleDouble folder).

If you are referring to the loss of ._ files when running Netatalk on a macOS host, that is by design as the OS handles storage. You should never see ._ files since Darwin/xnu's VFS layer will handle it for non-HFS/APFS volumes via the "doubleagent" routines. What that means is even if you mount a FAT32 or exFAT device as a Netatalk share, a ._ file should automatically be generated by the OS with resource forks, finder info, etc. This will handle extended attributes as well since macOS stored a marshalled copy in the AppleDouble files.

[rdmark]

this is about metadata sidecar storage on OSes that are not macOS

tools including sit and unar can store metadata sidecars as ._ files on non-macOS systems last I checked, so one idea is that if Netatalk can read those natively, you can hypothetically unstuff a sit archive with them to a Netatalk volume and have it just work

the other usecase is for netatalk-client: xattr aren't portable enough, especially for large resource forks, to be usable in the kio-afp client, while Netatalk style .AppleDouble sidecars are cumbersome to handle in the client and easy to lose track of by users

this is my thinking right now anyways, happy to be proven wrong! more experimentation will be needed before deciding what to do here.

[NJRoadfan]

FWIW you still get those sidecar files on Linux and other OSes, but they are only created if the file has a resource fork.

Netatalk can already read 3rd party generated ._ files. There is a conversion function called ad_convert_osx() that does exactly that. One thing that Netatalk does require that the string Netatalk exists in the 16 "filler" bytes (offset +0x8) in the AppleDouble file header, otherwise the ._ file won't be hidden from the client when browsing directories (but they will still be read from). Netatalk also won't pull the FinderInfo from these files to update the FinderInfo in the org.netatalk.Metadata EA.

[rdmark]

@NJRoadfan thanks for the reminder how Netatalk handles this: I had forgotten about the ._ sidecar fallback for ResourceFork and FinderInfo. With PR Netatalk/netatalk-client#268 we are now using the same fallback from xattr to ._ sidecars for ResourceFork and FinderInfo, while also doing the same xattr check on the file system and falling back do .AppleDouble sidecars if unsuccessful. at the same time, I haven't aimed to completely mirror Netatalk's semantics, so there may be gaps.

now we have at least the same defaults and nominal compatibility with Netatalk shared volumes on the same host