Filesystems · intermediate
Hard link
A hard link is a directory entry that maps an additional pathname to an existing inode. All hard-linked names are peers for the same filesystem object; removing one name does not remove the object while another link or open reference remains. Ordinary hard links target non-directory objects because directory hard links are normally prohibited or tightly restricted to preserve filesystem structure.
Why it matters
Hard-link behavior explains safe replacement patterns, link counts, deduplicated directory trees, and why deleting a visible filename does not always free its storage.
Mental model
How to reason about hard link
The inode owns the metadata and content, while each hard link is merely another directory name pointing to it. The filesystem reclaims the object only after its link count reaches zero and no open file description still references it.
Analogy
A hard link is like adding another door to the same room. Neither door is the original room, and removing one door does not destroy the room while another entrance remains.
Examples
See the boundary, not just the happy path
Worked example · Create a second name
ln report.txt archive/report.txt; ls -li report.txt archive/report.txtBoth directory entries show the same inode number on the same filesystem, and the inode's link count increases. Editing through either pathname changes the same file content.
Worked example · Remove one link
rm report.txt; cat archive/report.txtrm unlinks the first directory entry. The second hard link still reaches the inode, so its content remains available.
Useful contrast · Copy creates an independent object
cp archive/report.txt report-copy.txtA normal copy creates another inode with separately changeable content. Equal bytes immediately after copying do not make the files hard links.
Common mistakes
Misconceptions to remove early
Calling one hard link the real file
The names are equivalent directory entries for the same inode. The filesystem does not preserve an original-name relationship among them.
Expecting hard links to cross filesystem boundaries
A directory entry stores an inode number from its own filesystem, so link normally rejects a target on another mounted filesystem. Symbolic links can store cross-filesystem paths instead.
Quick check
Can you predict the result?
1. After creating a hard link and unlinking the first pathname, what happens to the content?
- • It remains reachable through the other hard link.
- • It becomes a dangling link immediately.
- • It is copied into the other pathname at unlink time.
2. Why can a normal hard link not point to a file on another filesystem?
Keep building