What is the difference between soft links and hard links in Linux?

Think of a hard link as two entries in a phone book that both dial the same person. Deleting one entry does not affect the other because both connect directly to the real person. A soft link is more like a sticky note saying 'call this other number.' If that number gets disconnected, the sticky note becomes useless. That is the core difference between these two link types.

A hard link adds another directory entry that maps a filename to an existing inode. The inode is the real data structure on disk that holds file metadata (permissions, ownership, timestamps) and pointers to the actual data. When you create a hard link, the inode's link count goes up by one. Both filenames are equally valid, and there is no 'original' versus 'copy.' A symbolic link (soft link or symlink) is a completely separate file with its own inode. That inode's data contains the text of the target path. When the kernel encounters a symlink, it reads the stored path and redirects to that location, adding a hop of indirection.

Inside the filesystem (ext4, xfs, etc.), hard links work through the inode reference count stored in the inode table. When you run ls -l, the second column shows this count. The file's actual data blocks are only freed when the link count drops to zero AND no running process has the file open. This is why you can delete a log file that a running process still has open and the disk space will not be reclaimed until that process closes the file. For symlinks, the kernel stores the target path either directly inside the inode itself (for short paths, usually under 60 bytes on ext4) or in a separate data block. The kernel follows symlinks automatically during system calls like open(), but provides lstat() and readlink() for inspecting the symlink itself without following it.

In production, both types serve important roles. Hard links are used by package managers like rpm and dpkg to save space when multiple packages include the same file. Backup tools like rsnapshot use hard links to create space-efficient snapshots where unchanged files across backups share the same data. Symlinks are everywhere in deployment setups: /opt/payments-api/current might point to /opt/payments-api/releases/v2.4.1, letting you do atomic deployments by switching the symlink to a new release folder. The /etc/alternatives system on Debian uses symlinks to manage multiple installed versions of the same program.

A key restriction is that hard links cannot cross filesystem boundaries because inode numbers are only unique within one filesystem. Trying to ln across mount points fails with 'Invalid cross-device link.' Hard links to directories are also blocked on most filesystems to prevent loops that would break tools like find and du. Symlinks can become dangling (broken) if the target is moved or deleted, causing confusing 'No such file or directory' errors. In Docker containers, symlinks pointing to absolute paths may resolve differently depending on the container's filesystem layout, leading to subtle deployment bugs. Always use readlink -f to resolve the final target of a symlink chain when debugging.