Linux Hard Links and Symbolic Links: Understand the Difference

Two filenames can lead to the same content, but their relationship determines what happens after a rename, replacement or removal. Linux hard links and symbolic links serve different needs. Confusing them can make a supposed backup change along with the working file.

This article concerns ordinary files on Linux with GNU Coreutils. Inspection commands do not modify data. Create example links only in a dedicated test directory without sudo.

1. A hard link adds a name, not a copy

GNU Coreutils describes a hard link as another name for the same file and inode within one filesystem. Neither name is inherently the original. Ordinary hard links cannot cross filesystem boundaries and are not the usual way users link directories.

If report.txt and report-hard.txt name the same file, an in-place content edit is visible through both. A hard link therefore does not provide an independent recovery copy after incorrect writes.

2. A symbolic link stores a target path

The Linux symlink manual describes a special file containing another object's pathname. The target may be on another filesystem or may not exist. Relative targets are interpreted from the directory containing the link, not the reader's working directory.

3. Inspect before acting

Assume a small report.txt already exists in your test directory and neither destination name exists:

ln report.txt report-hard.txt
ln -s report.txt report-soft.txt
ls -li -- report.txt report-hard.txt report-soft.txt
readlink -- report-soft.txt

The two hard-link names should show the same inode in that filesystem; the symlink should display report.txt as its target. Actual inode numbers vary. Reading a link's stored target does not establish target existence or permission to open it.

Do not add -f merely to overcome an existing destination. Confirm the directory and intended object first. No deletion is required for this exercise.

4. Why saving can separate the names

An editor's save operation might modify an existing file, or create a temporary file and rename it over the old path. The latter replaces that pathname with a new file while the other hard link still names the old one.

If results differ from expectations, examine how the application saves rather than concluding hard links failed. For symlinks, also determine whether the tool follows the link to modify its target or replaces the link itself.

5. Operational uses and limits

A symlink can offer a stable path to an application release directory. Switching it does not automatically solve open file handles, caches, database migrations or service restarts. Test the complete deployment procedure, not simply whether link creation succeeds.

Backup and synchronization tools may preserve links, follow targets or preserve hard-link relationships depending on their options. Read the relevant behavior. Avoid privileged writes through paths controlled by untrusted users: links can change the effective destination.

6. Selection checklist

• Another name for one file in one filesystem: consider a hard link.
• A pathname reference or directory target: consider a symlink.
• An independent recovery copy: use suitable copying or backup, not a link.
• Compare filesystem identity along with inode numbers.
• Test save, replacement and synchronization with the actual application.

Understanding links means understanding where names lead and how tools access them. Inspect first, experiment narrowly and never mistake a link for an independent copy.