Are org.netatalk.Metadata xattrs ever valid on client-side macOS files?

[JDLH]

I recently had a bad problem with my macOS client hanging when I tried to copy some files and directories from there to a server running Netatalk. I narrowed it down to a file, .DS_Store, which was present in some of the directories. This files each had an extended attribute ("xattr") named org.netatalk.Metadata . If I deleted that xattr, the files and their directories did not cause macOS to hang.

As far as I can tell from my investigations, Netatalk adds the org.netatalk.Metadata xattr to server-side files in order to store certain AppleDouble metadata. These xattrs are only needed on the files stored in the server file system. I suspect that Netatalk would not send them to clients. But these files are years old, they have migrated from client to one server to another server to another client. It is quite possible that at one point, they were copied directly from a file server's file system directly to a client, bypassing Netatalk.

I am tempted to prevent future problems by deleting an org.netatalk.Metadata xattr from every file on my client computer's file system. If any are visible from the client view of files on the server, I'd like to delete those xattrs also. But I'd like to be sure I won't delete any xattrs which ought to be there.

So, are org.netatalk.Metadata xattrs ever valid on client-side macOS files?

And, are they ever valid in the client-side macOS view of files delivered via AFP on a Netatalk server? If Netatalk adds such an xattr to a server-side file, for its own purposes, will it let the client see and delete that xattr? And if so, does any data loss result from the client deleting it?

For what it's worth, this is what the extended attribute in question contained:

% xattr -pxsl org.netatalk.Metadata  "/path/to/my/notes/_.DS_Store_hangs_AFP+Finder_2025-03-06"
org.netatalk.Metadata:
00000000  00 05 16 07 00 02 00 00 00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00 00 08 00 00 00 04 00 00  |................|
00000020  00 9A 00 00 00 00 00 00 00 08 00 00 01 62 00 00  |.............b..|
00000030  00 10 00 00 00 09 00 00 00 7A 00 00 00 20 00 00  |.........z... ..|
00000040  00 0E 00 00 01 72 00 00 00 04 80 44 45 56 00 00  |.....r.....DEV..|
00000050  01 76 00 00 00 04 80 49 4E 4F 00 00 01 7E 00 00  |.v.....INO...~..|
00000060  00 04 80 53 59 4E 00 00 01 86 00 00 00 08 80 53  |...SYN.........S|
00000070  56 7E 00 00 01 8E 00 00 00 04 20 20 20 20 20 20  |V~........      |
00000080  20 20 40 10 00 00 00 00 00 00 00 00 00 00 00 00  |  @.............|
00000090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
000000F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00000160  00 00 28 50 65 00 28 50 65 00 80 00 00 00 29 C1  |..(Pe.(Pe.....).|
00000170  34 E1 00 00 00 01 00 00 00 00 00 00 00 00 C4 BE  |4...............|
00000180  96 00 00 00 00 00 3E AF 5C 5D 00 00 00 00 FE FF  |......>.\]......|
00000190  1E                                               |.|
00000191

It looks to me as if this extended attribute is 401 bytes long. And what I see in Netatalk source code, atalk/adouble.h#L129-L135, that this structure should be 402 bytes long. I did see a message in my Netatalk server's log,

Mar 04... afpd[65958] {ad_open.c:801} (error:ad): ad_header_read_ea("/server/path/etc/.DS_Store"): short metadata EA

So maybe the content of this xattr is corrupt (short by 1 byte), and maybe that caused Netatalk to react in a way which in turn caused my macOS client to hang. But diagnosing that is not terribly important to me, if I can confidently delete such xattrs from all my client files.

By the way, I have had my most important digital files on servers, delivered by Netatalk to AFP macOS clients, for decades. I use Netatalk in this way every day. My deepest thanks to everyone who has worked on this software, for all the value they have delivered to me. Thank you!