In Linux, what does a file's inode number identify, and why does copying a file with cp produce a new inode number while renaming it with mv inside the same filesystem does not?

## What the number actually is Each filesystem maintains its own numbered table of inodes. A directory entry is a (name, inode number) pair, and `ls -i` or `stat -c '%i'` prints that number. Because the numbering is per filesystem, the same inode number will regularly appear on `/` and on `/home` for two entirely unrelated files. That is why identity comparisons use the pair of device ID and inode number: ```sh $ stat -c '%d %i %n' a.txt b.txt 2049 131074 a.txt 2049 131074 b.txt # same device, same inode -> hard links to one file ``` A program does this with `stat()` and comparing `st_dev` and `st_ino`; on the command line `find -samefile` does it for you. Inode numbers are also reused: once an inode is freed, the filesystem may hand the same number to the next file created. So an inode number is a *current* identity, not a durable name you can store and come back to weeks later. ## Rename moves the name, not the file `mv old new` inside a single filesystem is the `rename()` syscall. It edits directories: the entry disappears from the source directory and appears in the destination directory, still carrying the same inode number. Nothing about the file object changes. Consequences worth being able to state out loud: - Data is not read or written, so renaming a 40 GB file is instant regardless of size. - Open file descriptors keep working and keep writing to the same inode. A daemon logging to a descriptor it opened as `/var/log/app.log` continues writing after that path is renamed to `app.log.1` — it is writing to the inode, and the descriptor never consulted the name again. - Other hard links to the inode are unaffected; the link count does not change, because one entry was removed and one added. - Permissions, owner, size and `mtime` are preserved. The inode's `ctime` (status-change time) is updated, and both affected directories get new `mtime` and `ctime`, because their contents changed. - Rename onto an existing name is atomic: `rename()` replaces the destination entry in one step, and nobody ever observes the path missing. That is the basis of the write-temp-then-rename pattern used for safe config updates. ## Copy creates a different file `cp src dst` opens the source, creates the destination, and writes bytes into it. Creation allocates a new inode, so the destination has a different inode number, a fresh link count of 1, timestamps of now, and ownership by the copying user with permissions filtered through the umask. `cp -p` (or `-a`) asks for mode, ownership and timestamps to be preserved, but even then the inode number is new — preservation copies *attributes*, it does not share the inode. `cp -l` makes hard links instead of copies, and `cp --reflink` on a copy-on-write filesystem shares the underlying blocks while still creating a separate inode. Because a copy is a new file, anything holding the old inode open keeps seeing the old content, and any other hard link to the source is unaffected. ## Where this bites people The classic surprise is editing. Many editors do not write into the existing inode; they write a temporary file and rename it over the target. That is deliberately safe against a crash mid-write, but it means the file gets a **new inode**: hard links to the old inode are silently orphaned from your edit, and any process tailing the file by descriptor keeps reading the old, now-nameless inode. This is exactly why `tail -f` (follow the descriptor) and `tail -F` (follow the name, reopen when it is replaced) exist as separate options. The second is log rotation. Renaming a log file leaves the writing daemon happily appending to the same inode, now called `app.log.1`, and the newly created `app.log` stays empty forever. That is why rotation must either signal the daemon to reopen its logs after the rename, or use copy-then-truncate to keep the same inode in place. Both approaches are consequences of the same fact: the descriptor points at the inode, and the name is not part of it. The third is scripting identity checks. Comparing paths does not tell you whether two names are the same file, and comparing inode numbers alone across mount points produces false positives. Compare the device and inode together, or ask `find -samefile`.