In this chapter
We'll meet the file descriptor — a real, live handle a running program holds after opening a file, connected directly to the inode rather than the name, and the second real mechanism (alongside the link count) that can keep a file's data alive after its name disappears.
The Problem in Real Life
Sarah checks the backup service's logs from the night the invoice "vanished." "Here's something interesting," she says. "The nightly backup job opened this exact file at 2:03 AM — and as far as I can tell, it might still be running."
Mike frowns. "What does 'opened' even mean, technically? Isn't that just... reading it?"
If the backup already read the file, why would it still matter that it's 'open'?
Mike
A File's Name vs. A Program's Live Handle to It
A live connection, not a snapshot
Opening a file hands back an ongoing, real connection to its inode — held open for as long as the program keeps it.
Independent of the file's name
An open descriptor points at the inode directly — removing a file's name doesn't disconnect a program that already has it open.
File Descriptors
A file descriptor is a real, live handle a running program holds after it opens a file — a small number, private to that program, that the operating system uses to track an active, ongoing connection to a specific inode. It's genuinely separate from both the file's name and its link count.
- Opening a file creates a real, live connection — not a snapshot. When a program calls something like
open("/data/invoices/2026/inv-4471.pdf"), the operating system doesn't hand back a copy of the file's content. It hands back a small integer (the file descriptor) that represents an ongoing, real connection directly to that file's inode, held open for as long as the program keeps it — which, for a slow backup job, can be minutes or genuinely longer. - The descriptor points at the inode directly, not at the name. Once a file is open, the running program's connection is to the real inode itself, through the operating system's own internal open-file table — not to the path string that was typed to open it. This matters precisely because it means removing the file's name from its directory, while a program still holds it open, doesn't disconnect that program at all; its file descriptor keeps working exactly as before.
- Closing releases the connection; it doesn't erase anything on its own. A program calling
close()on its file descriptor simply ends its own use of that connection — it's a completely separate, real event from anything happening to the file's name or its link count. A file can have zero open descriptors and still have a name; it can have a removed name and still have open descriptors, held by some other running program entirely. - The operating system genuinely keeps every open file 'alive' while any descriptor references it. This is the real second half of this Act's own key mystery-solving mechanism: an inode's actual data isn't just protected by its link count (previous chapter) — it's also protected by any process that still holds it open, descriptor in hand, regardless of what's happened to its name in the meantime.
GreenMart's own backup job holding an open file descriptor on the invoice, from before its name was ever removed, is now a real, plausible piece of this Act's own mystery — not yet the full answer, but a genuine second thread, alongside the link count, that the closing chapter ties together.
Key Takeaway
An open file descriptor is a live, real connection straight to an inode — independent of the file's name, which means a program that already has a file open keeps working normally even after that file's name is removed from every directory.
Why This Matters
Real production incidents at companies like GreenMart — disk usage that won't drop after a "delete," a log file that keeps growing invisibly after rotation — trace directly back to this exact mechanism: some running process still holding a file open, keeping its real data alive independent of its name.
GreenMart now has both real halves of this Act's central mystery: a link count (previous chapter) and an open file descriptor (this chapter), each independently capable of keeping a file's actual data alive after its name is gone. The next chapter shifts focus to how a file's content is actually located on disk once an inode is found.