Linux Tutorial / Hard Links vs. Symbolic Links in Linux: Differences and Examples

A hard link is another name for the same file inode, whereas a symbolic link is a separate entry that stores a path to another location. Both offer another way to reach a file, but they behave differently when the original name changes or a file-system boundary is involved. In this lesson, you will create both links and observe the difference.

Two ideas behind file links

A directory entry such as report.txt supplies a name used in a path. The file system manages the file's metadata using an inode. Adding a hard link creates another name for the same inode. If one of those names is removed, the other still gives access to the file as long as it remains.

A symbolic link is its own entry containing the path string of its target. The system follows that path when you open the link. If the named target disappears or moves, the link can remain while access through it fails. This is called a broken link.

Create a practice file and both links

Work inside a new directory in your home folder. If ~/linux-course-09-practice already exists, choose a different name. The mkdir command below fails when the directory already exists. Stop if that happens: continuing might overwrite an existing file.

mkdir ~/linux-course-09-practice
cd ~/linux-course-09-practice
pwd

Check that pwd names the directory you just created before making a file. The following printf writes one line into original.txt.

printf 'version 1\n' > original.txt
ln original.txt hard.txt
ln -s original.txt shortcut.txt

The first ln uses its default behavior to create a hard link. The second creates a symbolic link with -s. shortcut.txt stores the relative path original.txt. Interpret that path relative to the directory containing the link, not the shell's current working directory.

Inspect inodes and the link target

Use GNU stat to display inode number (%i) and hard-link count (%h). readlink prints the path stored in a symbolic link.

stat -c '%i %h %n' original.txt hard.txt shortcut.txt
readlink shortcut.txt

Actual inode numbers differ by system, but original.txt and hard.txt should share a number and show a link count of two, as in this illustration. shortcut.txt has a different inode.

123456 2 original.txt
123456 2 hard.txt
789012 1 shortcut.txt
original.txt

These numbers are examples, not measured results. The relative path original.txt printed by readlink resolves within the directory holding the link, so all three names currently give access to the same content.

cat original.txt
cat hard.txt
cat shortcut.txt

Each command prints version 1. Identical content, however, does not mean the three names have the same underlying structure.

What if the original name changes?

Rename original.txt inside the practice directory. hard.txt remains readable because it names the same inode. shortcut.txt still points to the old path original.txt, so it becomes broken.

mv original.txt renamed.txt
cat hard.txt
readlink shortcut.txt

cat hard.txt prints version 1, while readlink shortcut.txt still prints original.txt. At this point, cat shortcut.txt should report that the target cannot be found. To make a link to the new name in the same directory, you could run ln -s renamed.txt new-shortcut.txt.

Removing a symbolic link with rm shortcut.txt normally removes the link itself, not the target. A trailing slash or a command aimed at a file inside a linked directory can change what a path means, however. Check the exact target before deleting anything.

Which link should you use?

Use a hard link when you want another name for a file on the same file system and want the file to remain accessible if one name disappears. A symbolic link is more flexible when you need to refer to a directory or a path on another file system, or want the destination to be visible as a path. If you plan to move the symbolic link or rename its target, remember that a relative target is interpreted from the link's own directory.

For more on destination handling and options, see the ln command guide. The readlink guide explains the stored target path and its resolution in more detail.

Official documentation

The GNU Coreutils ln documentation covers hard and symbolic links, and the GNU readlink documentation covers target-path output.