In this chapter
We'll close this Act's own mystery for good: delete only removes one name and decrements one link count, and a file's actual data is freed only once that count reaches zero AND no process still holds it open — the exact, complete reason GreenMart's invoice was never really gone.
The Problem in Real Life
Sarah lays out everything found across this Act: the archiving script's hard link, the backup job's still-open file descriptor from 2:03 AM. "Here's the real, complete answer," she says. "The invoice was never actually gone. Two genuinely separate things were keeping it alive at once."
Mike finally sees the whole shape of it. "So 'delete' was never really one single action at all."
So what does 'delete' actually mean, underneath all this?
Mike
"Delete" as One Action vs. Two Real, Independent Conditions
Delete removes a name, not a guarantee
Unlinking a file only removes one directory entry and decrements the link count — it doesn't, by itself, free anything.
Two real conditions, both required
Data is only actually freed once the link count is zero AND no open file descriptor remains — either alone keeps it alive.
Why Delete Doesn't Mean Gone
What most people call "deleting a file" is, underneath, a single real operation — commonly called unlink — that removes exactly one directory entry and decrements its inode's link count by one. It is not, by itself, a guarantee that any actual data goes anywhere at all.
- Unlink removes a name, not necessarily data. Calling delete on a file's name performs exactly the hard-link chapter's own removal step: the directory entry is gone, and the inode's link count drops by one. If that count is still above zero afterward — because another hard link exists somewhere else, as GreenMart's archiving script had quietly created — the actual data is completely untouched, and every other name still pointing at that inode keeps working normally.
- Reclamation needs TWO real conditions, both true at once. Even once the link count genuinely reaches zero, the file system still checks one more thing before actually freeing the data blocks: is any process, anywhere, still holding this inode open through a file descriptor (the earlier chapter's own mechanism)? Only when the link count is zero AND no open file descriptor remains does the file system actually mark the data blocks free and reusable.
- GreenMart's own real, complete answer. The invoice's original name was removed — link count dropped from 2 to 1, because the archiving script's hard link was still there. Separately, the nightly backup process had opened the file at 2:03 AM and, due to an unrelated real bug, never closed its file descriptor — meaning even after the link count eventually dropped further, that open descriptor alone would have kept the data alive regardless. Two genuinely independent safety nets, either one alone sufficient, both actually present at once.
- Why disk usage didn't drop — the real, final piece. Mike's original assumption — "delete it, and the space comes back" — was reasonable, but skipped this real distinction entirely: space is only reclaimed once BOTH conditions clear. As long as either the link count is above zero or any file descriptor remains open, the actual bytes stay allocated on disk, fully intact, regardless of how many names have been removed.
| Link Count | Open File Descriptors | Data Actually Freed? |
|---|---|---|
| > 0 | any | No — at least one name still reaches it |
| 0 | > 0 | No — a running process still holds it open |
| 0 | 0 | Yes — this is the only real condition that frees the data |
This is the exact real rule GreenMart's invoice satisfied neither of, for two separate, genuine reasons, which is exactly why its data never actually went anywhere.
GreenMart closes this Act with the mystery it opened fully, honestly solved — not through a guess, but through the exact real mechanisms built up chapter by chapter: what an inode tracks, what a link count means, what an open file descriptor guarantees, and what a hard link genuinely is. "Delete" was never one action; it was always these two real, separate conditions, both finally clearing at once.
Key Takeaway
"Delete" only removes one name and decrements one count — a file's actual data is freed only once its link count reaches zero AND no process still holds it open, which is the complete, real answer this whole Act was built to reach.
Why This Matters
This exact mechanism explains real, everyday operational mysteries GreenMart's own team will meet again — a log file "deleted" during rotation that keeps growing invisibly because a process still has it open, or a disk that won't free space until every process referencing a removed file is finally restarted. It's also, less happily, why deleted files are so often still recoverable — a real security and compliance consideration worth GreenMart being deliberate about.
GreenMart closes Act 3 with a complete, real understanding of the file system layer underneath every folder icon it will ever click — names, inodes, permissions, links, journaling, and now, precisely, what delete actually does and doesn't guarantee. Act 4 turns to a very different real problem: GreenMart's pages quietly serving stale prices and old inventory counts, the cache nobody at GreenMart designed on purpose.