Two Linux filenames can refer to the same underlying file rather than separate copies. Before editing an apparent duplicate, compare its device number and inode number with the other name. For ordinary regular files, matching both values identifies the same filesystem object at the moment of inspection. The hard-link count adds context, but an identical filename, size or inode number alone is not enough.
This matters when investigating a backup directory, unpacked dataset or application workspace. An in-place write through one hard link can change the data seen through another. Do not assume that a second pathname provides an independent backup.
Inspect both paths without modifying them
The following example uses GNU coreutils stat on Linux. Substitute two actual file paths, keeping the quotation marks if their names contain spaces. The command reads metadata; it does not alter the files.
stat -c 'name=%n device=%d inode=%i links=%h type=%F' -- '/path/to/first-file' '/path/to/second-file'The GNU stat manual defines %d as the device number, %i as the inode number and %h as the number of hard links. Read the file type too: this workflow concerns regular files, not an attempt to create hard links to directories.
- Same device and inode: both regular-file paths identify the same object at inspection time.
- Same inode, different device: do not call them the same file. Inode numbers are not globally unique across filesystems.
- Different inode: the paths do not identify the same inode in this comparison. They might still contain identical bytes.
- More than one hard link: additional names exist, but the count does not tell you where they are.
Separate hard links from symbolic links
By default, this stat command reports a symbolic link itself instead of following its target. If either result says symbolic link, pause before interpreting the pair as ordinary files. To inspect the resolved target deliberately, repeat the comparison with the GNU -L option:
stat -L -c 'name=%n device=%d inode=%i links=%h type=%F' -- '/path/to/first-file' '/path/to/second-file'Matching target metadata after dereferencing does not mean the two directory entries are hard links. One might simply be a symbolic link pointing to the other. Record which command you used. A broken symbolic link can make the dereferenced inspection fail; that error is not evidence that a regular file is empty or safely disposable.
Practise with two names in a disposable directory
This Bash example creates a small text file and a second hard-link name in a new temporary directory. It uses no privileged access and does not touch existing application files. Keep the printed directory path so you can inspect or remove only that exercise directory later.
demo=$(mktemp -d)
printf 'original note\n' > "$demo/first.txt"
ln -- "$demo/first.txt" "$demo/second.txt"
stat -c 'name=%n device=%d inode=%i links=%h type=%F' -- "$demo/first.txt" "$demo/second.txt"
printf 'Exercise directory: %s\n' "$demo"Expect matching device and inode values, regular-file types and a link count of two for this isolated example. The exact numeric identifiers depend on your machine. The GNU ln manual documents that ln creates hard links by default, while its symbolic option creates symbolic links. Here the original target must already exist and the new destination name must not.
Choose a safe response before editing or deleting
If your goal is independent working copies, create an ordinary copy using an approved destination and verify the new file’s metadata before editing. Retain a separate recoverable backup where required. Do not experimentally overwrite either production name to prove the relationship.
Also consider how the application saves changes. An in-place modification affects the shared object, while a program that saves by replacing a directory entry may produce a new inode instead. Therefore, a link relationship observed now is not a promise about what an editor or deployment tool will preserve later.
If the actual issue is unexpectedly low disk consumption rather than shared file identity, see checking sparse-file sizes. Logical size and allocated storage answer a different question from whether two names share an inode.
Quick questions and handover checklist
Does equal size prove a hard link? No. Compare device and inode identifiers. Even byte-for-byte equality only establishes matching contents, not shared identity.
Is this a permanent guarantee? No. Files can be replaced while you inspect them. For active workloads, coordinate an approved quiet period or application-aware investigation rather than racing ongoing changes.
For a useful handover, record both full paths, the command used, inspection time, file types, device/inode pairs and link counts. Keep access errors visible; do not weaken permissions just to collect metadata.
Safety: This tutorial is for educational purposes. Test in a disposable environment before production use. The site owner is not responsible for misuse, damage, data loss or production issues.
