In this chapter
We'll open up the inode itself — a real, fixed-size record holding a file's size, owner, permissions, timestamps, real pointers to its actual content, and a link count that turns out to be the exact key to this Act's own missing-invoice mystery.
The Problem in Real Life
Sarah finds the invoice's inode number from the last chapter's walk. "This number," she says, "points at a real record called an inode — and it's got more in it than I think you're expecting."
Mike leans in. "More than just... where the file is?"
I figured the number just says 'the file is over here.' What else could it possibly need?
Mike
One Number vs. A Full Real Record
Everything except the name
An inode stores size, owner, permissions, timestamps, and real data pointers — but genuinely no name field at all.
The link count — this Act's key number
Every inode tracks how many directory entries point at it — starting at 1, and the real key to the missing-invoice mystery.
Inodes & File Metadata
An inode (short for "index node") is a real, fixed-size record the file system keeps for every single file — and notably, it holds everything about that file except its name. Names, as the last chapter showed, live in directories. Everything else lives here.
- What an inode actually stores. Real file size, in bytes. Real owner and group (the next-but-one chapter, Permissions & Ownership, builds directly on this). Real permission bits — who can read, write, execute. Real timestamps — when the file's content last changed, when its metadata last changed, when it was last accessed. And, critically, real pointers to the actual data blocks (Act 1's own vocabulary) holding the file's content — the next chapter, How Files Find Their Blocks, goes deep on exactly how those pointers work.
- The field this whole Act is quietly building toward: the link count. Every inode also stores a real number — how many directory entries, anywhere in the whole file system, currently point at this exact inode. A brand-new file's inode starts this count at 1. This single number turns out to be the real key to GreenMart's missing-invoice mystery, and two chapters ahead (Hard Links) shows precisely how it can become more than 1.
- Why the name genuinely isn't in here. This is worth sitting with: an inode has no name field at all. The name "inv-4471.pdf" exists only as an entry in some directory's own table, pointing at this inode's number. Rename the file, and only that directory entry changes — not one field inside the inode itself is touched, which is exactly why renaming a file, even a huge one, is a near-instant real operation, not one that has to copy any actual data.
| Field | Real Example Value |
|---|---|
| Size | 184,203 bytes |
| Owner / Group | greenmart-app / staff |
| Permissions | rw-r----- |
| Modified time | 2026-08-14 09:12:03 |
| Data block pointers | → real disk block addresses (next chapter) |
| Link count | 1 (starts here — this Act's own key number) |
Notice what's missing: no name field anywhere. The name lives entirely in a directory entry, not in the inode itself.
GreenMart now has the real vocabulary this whole Act has been quietly assembling: a name lives in a directory, and everything else — size, ownership, permissions, timestamps, the real pointers to actual content, and a real link count — lives in the inode that name's directory entry points at.
Key Takeaway
An inode holds everything about a file except its name — including a real link count that tracks how many directory entries point at it, the single number that eventually solves the missing-invoice mystery this Act opened with.
Why This Matters
Real, everyday behavior GreenMart relies on — why renaming a huge file is instant, why permissions can be checked without opening a file's content, why a file system can report exact sizes and timestamps instantly — all comes directly from metadata being stored separately from both the name and the actual content, in this one real record.
GreenMart now has the real inode vocabulary — including the link count field this Act keeps circling back to. The next chapter finally opens the data-block pointers themselves: how a file's actual content gets located on disk once its inode is found.