Exercise 2: Why a File's Name Isn't in Its Own Inode — Possible Solution
====================================================================

Explanation:

Per the chapter's own description, an inode holds metadata about ONE
file -- permissions, owner, size, timestamps, and pointers to its
actual data blocks -- but the chapter is explicit that "the filename
itself is not stored in the inode." Instead, the chapter reveals that
"a directory is just a mapping of names to inode numbers." A directory
is itself a special kind of file whose own content is essentially a
list of (name, inode number) pairs -- it's the DIRECTORY's job to
associate a human-readable name with a specific inode, not the
inode's own job to remember what it's called.

-- What this reveals about what a directory actually is --
--
-- This means a directory isn't some fundamentally different kind of
-- object from a file -- it's really just a lookup table, translating
-- names a human finds meaningful into inode numbers the filesystem
-- actually uses internally to locate real file data. A single inode
-- can, in principle, be referenced by more than one name-to-inode
-- mapping -- possibly in different directories entirely, or multiple
-- names in the same directory -- since nothing about the inode itself
-- ties it to exactly one name. This directly explains how a HARD LINK
-- works, exactly as the chapter's own forward-pointer suggests: a
-- hard link is simply a second directory entry pointing at the exact
-- same inode number as an existing file, rather than a separate copy
-- of the file's own data -- both names genuinely refer to the same
-- underlying file, with neither one being "the real one" and the
-- other a copy.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains what a directory actually is (a name-to-inode-number
mapping, not a fundamentally different object) and connects this
directly to how hard links work, following through on the chapter's
own explicit forward-pointer rather than leaving it unaddressed.