xattr_full_name(9)

📦 version 7.3.1, in nixpkgs unstable

✨ xattr_full_name(9) — from the Kernel API Manual, bestie ✨

okay so you found the page for xattr_full_name, and honestly? she's a little helper with main character energy 💅 let's get into it.

🌸 NAME 🌸

xattr_full_name — computes the full attribute name from a suffix. that's it, that's the gig 🎀

🦋 SYNOPSIS 🦋

const char * xattr_full_name (const struct xattr_handler *handler ,
const char *name );

💖 ARGUMENTS 💖

  • handler — the handler of the xattr_handler operation 🫶 like, the one who owns the prefix, yk?
  • name — the name that got passed to the xattr_handler operation ✨

🌈 DESCRIPTION 🌈

okay so picture this: the get and set xattr handler operations get called with the remainder of the attribute name, right? like, after the handler's prefix has been skipped 👀 so for example, "foo" is what gets passed to the get operation of a handler whose prefix is "user.", and that's how you get the attribute "user.foo".

and the whole time? the full name is still right there — "there" in the name. like it never left, it's just hiding behind the prefix 🥺 iconic behavior honestly.

🔥 NOTE 🔥

heads up bestie, this one matters: the list xattr handler operation, when it's called from the vfs, gets passed a NULL name 😭 and some file systems use this operation internally, with varying semantics — so like, don't assume it always means the same thing, iykyk 💀

👑 SEE ALSO 👑

Kernel file ./fs/xattr.c — and the whole squad:

and that's the page!! 🧚 from ./fs, dated October 2026, and yeah — it's xattr_full_name(9) all the way down. slay, go read the whole crew, ily, bye 💜🍓

📦 where this page comes from