nfs_sillyrename(9)

📦 version 7.3.1, in nixpkgs unstable

💅 nfs_sillyrename 💅

ok so this is nfs_sillyrename(9) from the Kernel API Manual and bestie, the name is not a joke, the function is literally called that 🎀

✨ NAME ✨

nfs_sillyrename — do a silly-rename on a dentry 🦋

🌸 SYNOPSIS 🌸

int nfs_sillyrename (struct inode *dir , struct dentry *dentry );

🎀 ARGUMENTS 🎀

  • dir — the inode of the directory that contains dentry. it's the home, the address, the group chat this file lives in 💖
  • dentry — the actual dentry getting sillyrenamed. this is our main character ✨

👑 DESCRIPTION 👑

ok so picture this: NFSv2/3 is stateless 😭 the server literally has no idea when the client is holding a file open. none. zero. it's giving "we've never met" energy.

and that's a whole problem, because if an app has a file open and someone unlinks it, things get weird. so to stop that from happening, the client does a "silly-rename" 💅

what even is a silly-rename, you ask? it renames the file to a hidden file in the same directory 🫶 and then it just... waits. it only actually performs the unlink once the last reference to the file is put. patient queen behavior, honestly 👑

the final cleanup happens during dentry_iput.

🙈 tiny side note, and it's kind of a whole thing: NFSv4 is stateful and it actually has opens, so in theory an NFSv4 server could take responsibility for keeping open files referenced. the server would also need to guarantee that opened-but-deleted files survive reboots. but — and this is the important part — we may not assume a server does that. (RFC 5661 does provide an OPEN4_RESULT_PRESERVE_UNLINKED flag that a server can use to advertise that it does this; some day we may take advantage of it.) so like, someday. not today. ⭐

🔥 SEE ALSO 🔥

Kernel file ./fs/nfs/unlink.c plus the whole friend group:

and that's the page!! 💜 this one lives down in ./fs/nfs and it's dated October 2026 — so like, from the future, iconic of it honestly 🌈✨ slay, go rename something silly 🎀

📦 where this page comes from