Hard Links: Inodes, Link Counts, and File-System Behavior

Learn how Unix hard links use shared inodes, how to create, inspect, and remove them with ln, ls, stat, and rm, and how they differ from symbolic links.

A hard link is an additional directory entry that refers to an existing inode. It gives one regular file another pathname without making a second copy of the file's data.

Hard links are useful when several names should refer to exactly the same file. They are different from desktop shortcuts and from symbolic links: every hard-link name is an equal reference to the same underlying file.

Inodes and Directory Entries

An inode is a file-system data structure that identifies a file and records information such as its owner, group, permissions, timestamps, size, and references to the blocks containing its data. The inode does not normally store the filename.

A directory entry maps a filename in a directory to an inode number. The inode number is the numeric identifier for the inode within that file system. A directory can therefore contain two different names that map to the same inode number.

directory entry: report.txt       ─┐
                                  ├── inode 48192 ── file data blocks
 directory entry: report-copy.txt ─┘

link count: 2

In this model, report.txt and report-copy.txt are different names, but they identify the same file data and inode-associated metadata. Filename-specific information, such as the name and the directory containing it, belongs to the directory entry. Ownership, permissions, size, and most timestamps belong to the shared inode.

What a Hard Link Shares

File contents: reading or editing through either name accesses the same data.
Permissions and ownership: changing the inode's mode or ownership generally affects access through every hard-link name.
Size and timestamps: changes to the shared file are visible through all names.
File identity: the inode number is the same for every hard-link pathname.

Renaming one pathname changes only one directory entry. It does not move or copy the data, change the other hard-link names, or create a new inode.

Link Counts

The inode's link count is the number of directory entries that point to it. A newly created regular file normally has a link count of one. Creating another hard link increases the count; removing one pathname decreases it.

The file system can reclaim the file's storage when the link count reaches zero and no process still has an open file descriptor referring to the file. An open file descriptor is a process-held reference to an open file. This is why a running program can continue using a file after its last visible pathname has been removed.

Operation	Directory-entry effect	Link-count effect	Effect on file data
Create a regular file	Creates one name-to-inode entry	Normally becomes 1	Creates the initial file data
Create a hard link	Adds another name for the same inode	Increases by 1	No duplicate data is created
Edit through any hard-link name	Names remain unchanged	Unchanged	Changes shared data seen through every name
Rename one pathname	Replaces one directory entry with another name or location	Normally unchanged	Data and other names remain available
Remove one pathname	Removes one directory entry	Decreases by 1	Data remains if another link or open descriptor exists
Remove final pathname	Removes the last directory entry	Reaches 0	Reclaimed when no open descriptor remains

Creating and Inspecting a Hard Link

The basic command is ln without the symbolic-link option. Its argument order is:

ln SOURCE DESTINATION

The source is an existing file. The destination is the new directory-entry name. The source and destination must normally be on the same file system.

mkdir -p ~/hard-link-demo
cd ~/hard-link-demo
printf 'sample text\n' > report.txt
ln report.txt report-copy.txt
ls -li report.txt report-copy.txt

Typical output has the same inode number at the beginning of both lines and a link count of 2. File sizes and other shared metadata should also correspond.

stat report.txt

stat displays detailed metadata, including the inode number and the number of hard links. To verify the relationship directly, compare the inode numbers from ls -li or stat. Matching inode numbers for two names in the same file system indicate that they are hard-link names for the same inode.

Modify Through One Name

printf 'additional line\n' >> report-copy.txt
cat report.txt

The appended line appears when reading report.txt because both pathnames reach the same data blocks through the same inode. These are not two independently editable copies.

Find Other Names for an Inode

find . -xdev -samefile report-copy.txt

The -samefile test searches for files referring to the same inode as the specified file. The -xdev option prevents the search from descending into other file systems. The result is limited to directories that the current user can access.

Removing a Hard Link

rm removes a pathname, which means it removes a directory entry. It does not necessarily erase the underlying data immediately.

rm report.txt
ls -li report-copy.txt
cat report-copy.txt

After the command, report.txt is gone, but report-copy.txt still accesses the same file data. The link count normally falls from two to one. The remaining name is not a copy made during removal; it was already another equal reference.

When the final directory entry is removed, the file becomes unlinked. Its data may still be accessible to a process that already has an open file descriptor. Storage is released after the final pathname and final open reference are gone.

Hard Links and Symbolic Links Compared

A symbolic link is a special file containing a target path. It does not share the target's inode. A dangling symbolic link is a symbolic link whose stored path no longer resolves to an existing object.

printf 'sample text\n' > report.txt
ln report.txt report-hard.txt
ln -s report.txt report-symlink.txt
ls -li report.txt report-hard.txt report-symlink.txt

The hard link normally has the same inode number as report.txt. The symbolic link has its own inode and stores the path report.txt. Its displayed size commonly reflects the length of that stored path.

Characteristic	Hard link	Symbolic link
What the link references	An existing inode	A stored target pathname
Inode relationship	Shares the target inode	Has its own inode
Can cross file systems	Normally no; inode references are local to one file system	Yes, if the target path is reachable
Can normally refer to directories	Normally prohibited for ordinary users	Yes, subject to permissions and platform rules
Effect of deleting one target pathname	Other hard-link names still access the inode	The stored path may no longer resolve
Can become dangling	No, not because another pathname was removed	Yes
Typical listing appearance	Looks like a regular file and has the target's inode number	Often shown with `->` followed by its target path
Common uses	Multiple names for one regular file, backups, snapshots, and package storage	Path-based references to files or directories

rm report.txt
cat report-hard.txt
cat report-symlink.txt

The hard link still works because it refers directly to the inode. The symbolic link may fail because its stored target path, report.txt, no longer names an existing object. The symbolic link itself may remain, but it is dangling.

Hard-Link Restrictions

File-System Boundaries

A file system is the storage structure in which inode references are valid. Hard links normally cannot cross file-system boundaries because an inode number has meaning only within its own file system.

An attempted cross-device operation may produce an error such as Invalid cross-device link. For example, if /source and /destination are different mounted file systems, this may fail:

ln /source/report.txt /destination/report.txt

Use a symbolic link when a path-based reference is appropriate, or use cp when an independent copy is required. The actual boundary depends on the system's mount layout, so do not assume that two directories are on the same file system merely because they are visible in one directory tree.

Directories and Other Objects

Hard links are primarily used with regular files. Operating systems normally prohibit ordinary users from creating hard links to directories. Unrestricted directory hard links could create cycles in the directory graph, making traversal, deletion, backup, and consistency checks difficult or unsafe.

Platform, file-system, permissions, and security policies can impose additional restrictions, including restrictions on linking to files owned by other users or on protected system locations.

Use Cases and Cautions

Multiple names: several names can provide access to one regular file without consuming space for duplicate file contents.
Backups and snapshots: backup tools can use hard links to represent unchanged files in multiple backup views while storing the data once.
Package management: package data or shared resources may use hard links when identical file data should have multiple names.
Space efficiency: creating a hard link is usually much cheaper in storage than making a full copy, though all names still share the same contents.

The main caution is shared state. If someone edits through any hard-link name, every name shows the edit. If you need independent contents or independently managed metadata, use a normal copy:

cp report-copy.txt independent-report.txt
ls -li report-copy.txt independent-report.txt

The copied file should normally have a different inode number. See Modify File Permissions for related permission behavior and Check Disk Space for investigating storage usage.

Troubleshooting

“Invalid Cross-Device Link”

Cause: the source and destination are on different mounted file systems.

Resolution: use a symbolic link if a path reference is sufficient, or copy the file if separate data is needed.

Editing One Name Changes the Other

Cause: both names refer to the same inode.

Resolution: use cp before editing when independent contents are required, then verify that the inode numbers differ.

A Directory Hard Link Fails

Cause: the operating system or file system blocks directory hard links to prevent directory graph cycles.

Resolution: use a symbolic link for a directory reference when appropriate.

The Symbolic Link Fails but the Hard Link Works

Cause: the symbolic link stores a pathname and that pathname was removed or changed; the hard link still refers to the inode.

Resolution: update or recreate the symbolic link. Choose hard links only when same-file-system and regular-file restrictions are acceptable.

Disk Space Is Not Freed After Removal

Possible causes: another hard-link name still exists, or a running process still holds an open file descriptor for the removed file.

Resolution: search for other names with an inode-aware command such as find, and use system-appropriate tools to inspect processes holding deleted files open. Space is released after the final link and final open reference are gone.

Exam-Relevant Summary

A hard link is an additional directory entry referring to an existing inode.
Hard-link names share file contents, inode metadata, and inode number.
A directory entry maps a filename to an inode number; the inode stores file metadata and data-block references.
ln source destination creates a hard link when -s is not used.
ls -li and stat can show inode numbers and link counts.
rm unlinks a pathname. It does not necessarily destroy the data immediately.
Data is reclaimed when the link count is zero and no process holds an open file descriptor.
Hard links normally stay within one file system and normally cannot target directories.
A symbolic link stores a path, has its own inode, can cross file systems, and can become dangling.
Use cp for independent contents and metadata.