
Hard Link vs Symbolic Link: How I Almost Nuked My Mac
I wasted 50% of my disk space because I didn't know the difference between Copy and Link. Deep dive into Inode, the secret of `rm` command, and why `pnpm` is faster than `npm`.

I wasted 50% of my disk space because I didn't know the difference between Copy and Link. Deep dive into Inode, the secret of `rm` command, and why `pnpm` is faster than `npm`.
Why does my server crash? OS's desperate struggle to manage limited memory. War against Fragmentation.

If an OS is a collection of programs, who is the core? Identity of the Kernel that always stays in memory.

How OS creates the illusion of multitasking. Preemptive vs Non-preemptive, The Starvation problem, and how modern OSs use Multi-Level Feedback Queue (MLFQ) and Red-Black Trees (Linux CFS) to keep everyone happy.

Conductor of VMs. Is the CEO running it directly (Type 1), or hiring a manager (Type 2)?

As a junior developer, I was managing a Machine Learning dataset.
I had a 300GB image dataset (dataset_v1), and I needed to rearrange the folder structure for a new experiment.
Scared of messing up the original, I decided to Copy it (cp -r dataset_v1 dataset_v2).
Instantly, my MacBook screamed "Disk Full," and my build pipeline crashed. A senior engineer walked by and chuckled. "Dude, why did you copy the whole thing? Just use a Symbolic Link."
"What? Like a Windows shortcut?" "Similar, but different. Also, if the data is critical, you might want a Hard Link."
That day, I learned the ln -s command and dove into the abyss of the Unix filesystem: the Inode.
When we see a file icon in Finder/Explorer, we think, "That is the file." But to the OS (Linux/Unix/macOS), a file is split into two parts:
Shocking Fact: When you run
rm file.txt, you are NOT deleting the file data. You are Unlinking the filename from the Inode. The OS only reclaims the disk space when the Link Count of an Inode drops to zero.
ln target.txt hardlink.txttarget.txt and hardlink.txt share the exact same Inode number.hardlink.txt, target.txt changes too (because they are literally the same file data).target.txt), hardlink.txt survives.
ln -s target.txt symlink.txt.exe) is located.symlink.txt has its own unique Inode. It is a distinct file."./target.txt".target.txt)?
Error: No such file or directory./usr/bin/python -> python3.9
python3.10.brew (Homebrew) manages versions..zshrc and .vimrc in a Dropbox/config folder.~/) pointing to them.Hard Links seem safer (resilient to deletion) and faster. Why do we use Symlinks 99% of the time? Because Hard Links have Two Fatal Flaws:
find or backups) would run forever until they crash. The OS forbids this to prevent chaos.Symbolic Links solve both:
If you use Node.js, you know the pain of node_modules eating your disk.
If you have 10 projects using React v18:
node_modules 10 times.pnpm (Performant NPM) uses Hard Links intelligently (technically content-addressable store + hard links).
~/.pnpm-store) ONCE.node_modules to that global store.Result:
If you are running out of space on your MacBook, switch to pnpm. It's a life saver.
Hard Links are also the unsung heroes of Docker and CI Pipelines.
Docker images are built from layers. When you run docker build, Docker uses a Union File System (like OverlayFS).
This system allows different containers to share the same underlying image files.
If you run 10 Ubuntu containers, you don't use 10x the disk space. You use 1x space for the OS files, and each container only stores its diffs.
While not exactly "Hard Links" (it's more complex), the concept is the same: One physical data block, multiple pointers.
In GitHub Actions or Jenkins, restoring a massive node_modules cache (1GB+) can take time.
Modern package managers and CI tools use Hard Links to "hydrate" the cache instantly.
Instead of copying 100,000 files from cache to workspace, they just link them.
If your CI is slow, check if your caching strategy exploits this. Tools like Turborepo and Nx rely heavily on this linking magic to make Monorepo builds fast.
| Feature | Hard Link | Symbolic Link (Soft Link) |
|---|---|---|
| Identity | An alias (extra name) for the Inode | A separate file pointing to a path |
| Inode Number | Same as original source | New, unique Inode |
| If Source Deleted | File remains accessible (Data safe) | Link becomes Broken (Error) |
| Directory Support | No (System restricted) | Yes |
| Cross-Filesystem | No (Same partition only) | Yes (Anywhere) |
| Analogy | Nickname | Shortcut Icon |
rmUnderstanding links changed how I see file operations.
rm isn't a shredder; it's just a scissor cutting the name tag.
However, rm -rf / is still the scariest command.
It cuts every name tag, causing the OS to garbage collect (overwrite) everything. (No recovery possible).
Next time you need to duplicate a file/folder, ask yourself:
"Do I need a new copy? Or just a reference?"
Use ln -s. Or use pnpm. Your SSD will thank you.