Filesystems · foundation
Symbolic link
A symbolic link is a filesystem object whose content is a pathname used during path resolution to locate another object. Because it stores a path rather than an inode reference, its target can move, disappear, or reside on another filesystem.
Why it matters
Symlinks are common in toolchains, deployments, and configuration. Correctly reasoning about their stored text and resolution base prevents broken relative links and accidental operations on targets.
Mental model
How to reason about symbolic link
When pathname lookup encounters a symlink in a followed position, it substitutes the symlink's stored pathname and continues. An absolute target restarts at the process's root; a relative target starts from the directory containing the symlink.
Analogy
A symlink is a forwarding note containing an address. The note still exists if the destination moves, but following the old address then leads nowhere.
Examples
See the boundary, not just the happy path
Worked example · Create a relative deployment link
ln -s releases/2026-07 currentThe current symlink stores releases/2026-07. Because that text is relative, it resolves from the directory containing current, independent of the caller's later working directory.
Worked example · Inspect without following
readlink currentreadlink prints the pathname stored in the symlink. It does not prove that the resulting target currently exists.
Useful contrast · Hard link stores no target pathname
ln releases/2026-07/config.json config-hardlink.jsonThis hard link is another directory entry for the same inode. Unlike a symlink, it does not become dangling merely because the other name is removed.
Common mistakes
Misconceptions to remove early
Resolving a relative target from the caller's directory
The kernel resolves a relative symlink target from the directory that contains the symlink, not from the process's current working directory.
Reversing target and link name
The portable form is ln -s TARGET LINK_NAME. Reversing them either fails or creates a link somewhere other than intended.
Quick check
Can you predict the result?
1. From where is a relative pathname stored in a symlink resolved?
- • From the directory containing the symbolic link.
- • From the home directory of the link's owner.
- • From the working directory of whichever process created it.
2. Why can a symbolic link cross a filesystem boundary?
Keep building