In this chapter
We'll meet the symbolic link — its own small, real file storing a path, genuinely different from a hard link's shared-inode mechanism — see exactly why it can cross file systems and target directories, and why, unlike a hard link, it can dangle.
The Problem in Real Life
Sarah finds one more clue: a shortcut at /var/www/current-invoices that, when followed, lands somewhere else entirely — /data/invoices/2026/. "This one's genuinely different from the hard link we just found," she says. "This isn't a second name for the same inode at all."
Mike looks between the two mechanisms, now genuinely curious about the difference. "So what is it, then?"
Okay, so it's not a hard link — then what exactly is it?
Mike
A Second Name for an Inode vs. Its Own File Holding a Path
Its own file, storing a path
A symlink has its own real inode — its content is simply a path string, resolved fresh every time it's followed.
Can dangle — a hard link never can
Because a symlink isn't counted as a reference, its target can move or vanish, leaving a real, resolvable-to-nothing path behind.
Symbolic Links
A symbolic link (or symlink) is a genuinely different mechanism from a hard link, even though both are casually called "shortcuts." A symlink is its own real, small file — with its own real inode — whose actual content is nothing more than a path string, pointing at wherever it leads.
- Its own real file, not a second name for someone else's inode. Creating a symlink with something like
ln -s /data/invoices/2026 /var/www/current-invoicesallocates a brand-new, genuinely separate inode — small, but real, with its own link count starting at 1 — whose actual data is simply the text/data/invoices/2026. Following the symlink means the file system reads that path string and resolves it fresh, exactly the same real walk covered two chapters back, starting over from the target path. - This is why it can do two things a hard link genuinely can't. Because a symlink just stores a path — not a direct pointer to an inode number — it can point across file systems entirely (something a hard link, tied to one file system's own inode numbering, can never do), and it can point at a directory, not just a file (the very thing most systems block for hard links, to avoid creating reference loops).
- Real, honest fragility: the dangling link. Because a symlink only stores a path, and that path is only resolved at the moment it's followed, nothing stops the actual target from moving or being deleted entirely, leaving a symlink whose path genuinely no longer resolves to anything — a dangling symlink. Following one in that state returns a real "no such file" error, even though the symlink file itself still technically exists. A hard link, by contrast, cannot dangle: as long as its inode's link count is above zero, the data it points at is genuinely, guaranteed present.
- Removing a symlink never touches its target at all. Deleting
/var/www/current-invoicesremoves only that small symlink file — its own inode, its own small link count, going to zero and being reclaimed. The real directory it was pointing at,/data/invoices/2026/, and everything inside it, is completely unaffected; a symlink was never one of that directory's own real reference counts to begin with.
| Property | Hard Link | Symbolic Link |
|---|---|---|
| What it actually is | A second directory entry, same inode | Its own separate file, own inode, storing a path |
| Increments target's link count? | Yes | No — it's not counted as a reference to the target at all |
| Can cross file systems? | No | Yes |
| Can target a directory? | No (on most systems) | Yes |
| Can it "dangle" (target removed)? | No — data stays while link count > 0 | Yes — resolves to a real error if the target is gone |
GreenMart now has the full, real picture: the archiving script's hard link explained why the invoice's data survived losing its original name, and this symlink explains the second real clue — a convenience shortcut that was never counted as a reference to anything, and could genuinely have dangled without affecting the file's actual survival either way.
Key Takeaway
A symlink is its own small, real file holding a path — not a second reference to another file's inode — which is exactly why it can cross file systems and point at directories, and exactly why, unlike a hard link, it can dangle if its target ever moves or disappears.
Why This Matters
Real deployment tooling GreenMart likely already relies on — a current symlink pointing at whichever release directory is actually live, swapped atomically during a deploy — depends entirely on this exact mechanism working the way this chapter describes.
GreenMart now has both real link mechanisms fully separated: hard links share an inode and a link count; symlinks are their own small file storing a path, resolved fresh each time. The Act's final chapter ties every mechanism covered so far — link counts and open file descriptors both — into the complete, real answer to what "delete" actually means.