a hard link versus a symbolic link
Two ways to give a file a second name. One is to add another label pointing straight at the same physical book - now the book has two equally real names. The other is to write a sticky note that says 'go look for the book over there' - if someone moves or removes the original, the note points at nothing. The first is a hard link; the second is a symbolic link.
A hard link is a second directory entry that points at the very same inode as the original name. Both names are equally first-class - neither is 'the real one' - and the file's link count goes up by one. Because they share the inode, they share the data, the size, the permissions, everything. The file's data is freed only when the link count reaches zero, so deleting one name leaves the file fully intact under the other. Hard links cannot cross filesystem boundaries (inode numbers are only unique within one filesystem) and normally cannot point to directories. A symbolic link (symlink, or soft link) is a tiny separate file of its own, whose contents are just a path string pointing at another name. Following it means reading that path and looking it up fresh. A symlink can cross filesystems and can point at directories, but it can dangle: if its target is renamed or deleted, the symlink still exists but now points at nothing, and opening it fails.
Why it matters: the distinction shows up constantly. Hard links are how a file safely lives under two names with no fragile pointer; symlinks are how you make flexible shortcuts and version aliases (like libfoo.so pointing at libfoo.so.1.4). Knowing that a hard link shares the inode while a symlink merely stores a path explains every difference between them: why deleting the target breaks one but not the other, why one crosses filesystems and the other does not.
$ ln a.txt b.txt # hard link: b.txt and a.txt share one inode, link count = 2 $ ln -s a.txt c.txt # symlink: c.txt is a tiny file holding the string "a.txt" $ rm a.txt # b.txt still works (data lives on); c.txt now dangles
Remove the original: the hard link survives intact, the symlink is left pointing at nothing.
A hard link shares the inode, so all names are equal and the file lives until the link count hits zero; a symlink stores only a path string, so it can dangle, cross filesystems, and point at directories. They are genuinely different objects, not two words for one thing.