Choosing Between Hard Links and Symbolic Links on Unix Filesystems

The decision you face

When you need multiple names for the same data on a Unix‑like system, you have two built‑in mechanisms: hard links and symbolic links (symlinks). The choice affects backup size, cross‑filesystem portability, and how tools such as find or du behave. This guide states the constraints, compares the options in a compact table, explains the trade‑offs, and shows a concrete verification you can run today.

Constraints that drive the choice

• Filesystem boundary – Hard links share an inode, and inode numbers are unique only inside a single filesystem. You cannot create a hard link across two mounted partitions.
• Directory linking – The kernel forbids hard links to directories (except . and ..) to prevent cycles. Symlinks can point to directories freely.
• Target lifetime – Deleting the original file of a hard link leaves the data intact as long as at least one link remains. Deleting the target of a symlink creates a dangling reference.
• Backup and accounting – Backup utilities that count bytes per inode will see the data once for hard links but once per symlink (the symlink itself is tiny). Tools that follow links (du -L, rsync -L) will count the target data for symlinks.

Quick comparison

Property	Hard link	Symbolic link
Inode sharing	Yes – same inode number	No – distinct inode
Cross‑filesystem	Not allowed	Allowed
Can point to directory	No (kernel blocks)	Yes
Target deletion effect	Data persists while any link exists	Link becomes dangling
Size on disk	Only directory entry (few bytes)	Separate inode + path string (typically < 60 B)
Backup deduplication	Automatic (single inode)	Requires link‑aware backup
Risk of loops	None (no directory links)	Possible if symlinks form cycles

Trade‑off discussion

When hard links shine

Use hard links when you need multiple names for the same file on the same filesystem and you want the data to survive any single deletion. Typical scenarios:

• Versioned configuration files that must stay in sync without copying.
• Deduplicating large static assets (e.g., container image layers) inside a single volume.
• Creating a “snapshot” directory where each file is a hard link to the current version; removing a snapshot entry does not delete the data.

Because the kernel treats all hard links equally, standard tools (cp, mv, tar) preserve the link count automatically.

When symlinks are the right tool

Choose symlinks when you need:

• References that cross filesystem boundaries (e.g., /var/www/html -> /mnt/storage/web).
• Directory indirection (e.g., /etc/nginx/sites-enabled -> ../sites-available).
• A clear, human‑readable pointer that can be inspected with ls -l.
• The ability to replace the target without updating every reference (just move the target and the symlink still points to the new location if the path stays valid).

Beware of dangling symlinks after target removal and of recursive tools entering loops. Use find -L or realpath to resolve safely.

Concrete verification you can run now

The following steps create one hard link and one symlink to the same source file, then prove their differences. Run them in a directory where you have write permission (e.g., $HOME/testlinks). No root privileges are required.

mkdir -p ~/testlinks && cd ~/testlinks
# 1. Create a source file
echo 'original data' > source.txt

# 2. Create a hard link (same filesystem)
ln source.txt hardlink.txt

# 3. Create a symbolic link
ln -s source.txt symlink.txt

# 4. Verify inode sharing
ls -i source.txt hardlink.txt symlink.txt
# Expected: source.txt and hardlink.txt show the SAME inode number;
# symlink.txt shows a DIFFERENT inode.

# 5. Inspect link type and target
ls -l source.txt hardlink.txt symlink.txt
# Expected: hardlink.txt has no arrow, symlink.txt shows "-> source.txt".

# 6. Delete the original and observe
rm source.txt
cat hardlink.txt   # prints "original data" – data still present
cat symlink.txt    # error: "No such file or directory" – dangling symlink

# 7. Attempt a cross‑device hard link (will fail)
# Assuming /mnt/usb is a different mounted filesystem:
# ln source.txt /mnt/usb/crosslink.txt
# Expected error: "ln: invalid cross-device link"

What to check:

• ls -i confirms hard links share an inode.
• ls -l shows the l prefix and arrow for symlinks.
• After rm source.txt, the hard link still serves the data; the symlink is broken.
• The cross‑device attempt demonstrates the filesystem boundary rule.

Risks: The rm step permanently removes the original directory entry. If you need the original name later, recreate it with ln hardlink.txt source.txt before the removal.

Limitations and practical checks

• Hard links cannot be created for directories (except ./..) and cannot cross mount points. They also make du report the same blocks multiple times unless you use du -l (count each hard link once).
• Symlinks add a layer of indirection; stat on the symlink returns the link’s metadata, while stat -L follows it. Scripts that assume a regular file may misbehave on a symlink.
• To audit a tree for link types, run:

  find /path -type l -printf '%p -> %l\n'   # list all symlinks with targets
  find /path -type f -links +1 -printf '%p (inode %i, %n links)\n'   # files with >1 hard link
  

Bottom line

If you need multiple names for the same data on one filesystem and want the data to survive any single deletion, use a hard link. If you need to reference a file or directory across filesystems, or you want a visible, replaceable pointer, use a symbolic link. The table above and the verification commands give you a quick way to confirm the behavior on any Linux, macOS, or BSD system.