EXTATTR(9)

💖 EXTATTR(9) — the extattr page, bestie edition 💖

okay so this is extattr, from the Kernel Developer's Manual — it's all about virtual file system named extended attributes. yes it's kernel dev stuff. yes it's a lot. no you're not dumb. let's go 🦋

---

✨ NAME ✨

extattr — virtual file system named extended attributes

---

🌸 SYNOPSIS 🌸

#include <sys/param.h>
#include <sys/vnode.h>
#include <sys/extattr.h>

like, those are the headers you need, that's the whole vibe check 💅

---

🎀 DESCRIPTION 🎀

So named extended attributes let you attach extra meta-data to vnodes — and vnodes are the things representing files and directories, iykyk. The semantics of that extra data? It's literally a "name=value" pair situation. A name can be defined or undefined, and if it is defined, it's associated with zero or more bytes of arbitrary binary data. Zero bytes counts. Zero is a valid amount of bytes. iconic honestly.

Extended attribute names live inside a set of namespaces — and every single operation on an extended attribute is required to hand over the namespace that the operation refers to. No namespace, no entry, that's the rule. And if the same name shows up in multiple namespaces? Those extended attributes are stored and manipulated independently — they do not share, they do not merge, they are separate girlies. ✨

The following two namespaces are defined universally:

• EXTATTR_NAMESPACE_USER
• EXTATTR_NAMESPACE_SYSTEM

...although individual file systems may implement additional namespaces, or may just not implement these namespaces at all. 🙈 per-fs behaviour, always.

The intended semantics of those two:

• user attribute data — protected according to the normal discretionary and mandatory protections associated with the data in the file or directory. So it's got the same protection energy as the file itself.
• system attribute data — protected such that appropriate privilege is required to directly access or manipulate these attributes. Like, privileged. Don't just wander in.

Now the reading/writing tea ☕ — reads of extended attribute data may return specific contiguous regions of the meta-data, in the style of VOP_READ(9). But writes? Writes replace the entire current "value" associated with a given name. The whole thing. No partial writes, no little edits, it's a full swap. 💀

⚠️ and here's the big one: there are a plethora of file systems with differing extended attributes, so availability and functionality of these functions may be limited. Use them with awareness of the underlying semantics of the supporting file system. fr fr.

Also — authorization schemes for extended attribute data may vary by file system, and so may the maximum attribute size, and also whether any new attributes may be defined at all, or whether specific new attributes may be defined. So like, don't assume. 🫶

Extended attributes are named using a null-terminated character string. Depending on underlying file system semantics, this name may or may not be case-sensitive — so maybe Foo and foo are the same, maybe they're strangers. Depends on the fs. 🌈

The appropriate vnode extended attribute calls are:

• VOP_GETEXTATTR(9)
• VOP_LISTEXTATTR(9)
• VOP_SETEXTATTR(9)

those three. that's the trio. 👑

---

🔥 SEE ALSO 🔥

• VFS(9)
• VFS_EXTATTRCTL(9)
• VOP_GETEXTATTR(9)
• VOP_LISTEXTATTR(9)
• VOP_SETEXTATTR(9)

go read those too, bestie, they're the supporting cast 💜

---

👑 AUTHORS 👑

This manual page was written by Robert Watson. ty for your service, king 🫡💖

---

💀 BUGS 💀

okay so the interface does not provide a mechanism to retrieve the current set of available attributes. and yeah, it has been suggested that providing a NULL attribute name should cause a list of defined attributes for the passed file or directory — but this is not currently implemented. so, no. it doesn't do that. don't try it and be shocked. 😭

---

and that's the page!! this came from the Debian build of the manual, dated December 23, 1999 — yes, 1999, ancient, vintage, a classic. mwah 💅✨🎀