ksmbd_close_...ete_on_close(9)

✨ NAME ✨

Hiii bestie 🫶 welcome to the ksmbd_close_...ete_on_close(9) page from the Kernel API Manual — yes, that name is a whole tongue-twister, but we're locked in 💅 The function is ksmbd_close_disconnected_durable_delete_on_close, and its job is literally: drop a delete-on-close file kept present only by disconnected durable handles ✨

---

🎀 SYNOPSIS 🎀

The signature, bestie, exactly:

bool ksmbd_close_disconnected_durable_delete_on_close (struct dentry
       *dentry );

---

🦋 ARGUMENTS 🦋

• dentry — dentry of the file being opened. That's the one and only argument, no cap 🙈

---

💖 DESCRIPTION 💖

Okay so here's the lore 😭 A durable handle that was opened with delete-on-close gets preserved across a disconnect, which means a durable reconnect can reclaim it. Iconic behavior, honestly ✨ But if a new open — specifically a non-reconnect one — shows up for that same name instead, the disconnected handle has to give way. Sorry bestie, the new open is the main character now 💅

So we close handles like that, which applies their delete-on-close and removes the file once the last handle is gone; that lets the new open create a fresh file. Fresh file, fresh start, slay 🌱

And the careful little choreo: before closing, the caller's inode reference gets dropped, so the final close can promote S_DEL_ON_CLS to S_DEL_PENDING and unlink the file. That's the detail that makes the whole thing work, iykyk 🧚

---

⭐ RETURN ⭐

Returns true if a disconnected durable handle was closed. That's the whole boolean, bestie 🫶 true-core

---

🌈 SEE ALSO 🌈

• Kernel file ./fs/smb/server/vfs_cache.c
• ksmbd_update_fstate(9)
• ksmbd_vfs_compare_durable_owner(9)

---

mwah 💋 — source/version ./fs/smb/server, dated October 2026, page ksmbd_close_...ete_on_close(9). Bye bestie 🫶✨