NJRoadfan
commented
2 months ago The code that converts AD from v2 (.AppleDouble folders) to extended attributes and ._Files (resource forks) lives in ad_convert.c. One would have to make calls to read the extended attribute files in the .AppleDouble folder (usually in the form of MyFile::EA::AttributeName) and insert that data as a native extended attribute inside the file it belongs to. These calls appear to be in the libatalk/vfsdirectory.
For background, here is a discussion from @franklahm when the EA storage features were added to Netatalk: https://sourceforge.net/p/netatalk/mailman/netatalk-devel/thread/4242eef70909110631ra51f32pa70c85246cc00e62%40mail.gmail.com/#msg23527482
Any native MacOS X extended attributes stored in the .AppleDouble directory are NOT converted to filesystem EA. At least with 2.x shares, the files will remain orphaned in the .AppleDouble directory.
Note, the extended attributes I am referring to are the ones created by macOS, such as the infamous "com.apple.quarantine" and other metadata. Off hand, I don't know of any applications that store important data in EAs, but this is still considered data loss. The AFP commands to manipulate them didn't show up until OS X 10.4 with AFP 3.2 (FPSetExtAttr, etc.).
For folks only using netatalk for sharing with classic Macs, its a non-issue as OS9 and older don't use these types of EAs. All the classic file attributes (resource fork, FinderInfo, comments, color, etc.) are transferred properly. Its odd this was missed since netatalk 2.x supported OS X EAs already. I'm guessing they were pretty rare out in the wild back in 2009-10.
Reported by @NJRoadfan in https://68kmla.org/bb/index.php?threads/netatalk-4-0-future-proofing-apple-file-sharing.47958/post-543133