nfsd_get_case_info(9)

💅 nfsd_get_case_info(9) 💅

okay so this is a page from the Kernel API Manual, and it's literally all about nfsd_get_case_info — the little function that tells you whether a dentry cares about letter case or not. bestie, it's giving "small function, big responsibility" and we're obsessed 🎀

---

✨ NAME ✨

nfsd_get_case_info — get case sensitivity info for a dentry 🦋

---

🌸 SYNOPSIS 🌸

int nfsd_get_case_info (struct dentry *dentry , bool *case_insensitive ,
bool *case_preserving );

---

🎀 ARGUMENTS 🎀

• dentry — the dentry you're asking about, bestie. that's the one being queried 💖
• case_insensitive — gets set to true if the name comparison ignores case (so README and readme are the same vibe, no cap) 🙈
• case_preserving — gets set to true if the case is actually preserved on disk (so the letters stay exactly how you typed them, iconic behavior) ✨

---

🧚 DESCRIPTION 🧚

so here's the tea ☕ on casefold-capable filesystems: the flag lives on the directory, not on its entries. so if you hand it a non-directory dentry, it goes and queries the parent instead. periodt 🫶

but a directory gets queried as-is — including an export root, whose parent lies outside the export — because the whole point is to report the lookup behavior of its own contents 💅. and heads up: NFSD advertises fattr4_homogeneous as FALSE, so per-directory answers may totally differ within one export. not me having different rules in different rooms 😭

the probe runs with kernel credentials. case_insensitive and case_preserving describe the directory's structural lookup behavior — not the caller's identity. and there's a real reason for that: running under the calling client's mapped credentials would let per-client MAC policy on the parent directory turn this query into NFS4ERR_ACCESS, even though the underlying property is literally the same for every client. so yeah, we don't do that 🔥

okay now the important part, pay attention 🫶: when the filesystem does not expose case-folding state — meaning there's no ->fileattr_get, or the callback returns -EOPNOTSUPP / -ENOIOCTLCMD / -ENOTTY / -EINVAL — the outputs get filled with POSIX defaults (case-sensitive, case-preserving). the premise is that a filesystem with case-folding support would have wired up fileattr_get. so if it didn't bother, we assume the boring defaults 💀

---

👑 RETURN 👑

• 0 — outputs filled, we slayed 💖
• -EOPNOTSUPP — outputs filled to POSIX defaults (see above, the filesystem didn't expose the state)
• a negative errno (e.g., -EIO, -ESTALE, -ENOMEM) — and in that case the outputs are left unmodified, so don't go reading them like they mean something 🙈

---

🌈 SEE ALSO 🌈

Kernel file ./fs/nfsd/vfs.c, plus all these besties:

nfserrno(9), nfsd_lookup(9), nfsd_setattr(9), nfsd4_is_junction(9), nfsd_open_verified(9), nfsd_splice_read(9), nfsd_iter_read(9), nfsd_vfs_write(9), nfsd_read_splice_ok(9), nfsd_read(9), nfsd_write(9), nfsd_commit(9), nfsd_create_setattr(9), nfsd_symlink(9), nfsd_link(9), nfsd_rename(9), nfsd_unlink(9), nfsd_readdir(9), nfsd_filp_close(9), nfsd_removexattr(9)

---

and that's the whole page, bestie!! 🦋✨ this one comes from ./fs/nfsd, dated October 2026 — go off, kernel docs, you ate 💅🎀