Linux & Bash · Part I · Module 6 · Links and File Identity

Names, Inodes and What a Directory Really Contains

Four times now this course has told you something that was true and incomplete. [Chapter 2.1](/linux-bash/filesystem-hierarchy) said a directory contains entries, without saying what an entry is. [Chapter 2.5](/linux-bash/reading-the-long-listing) taught you to read a link count and promised an explanation later. [Chapter 3.3](/linux-bash/deleting-files-safely) said that deleting removes a name rather than a file, which raises an obvious question about what happens to the file. [Chapter 5.2](/linux-bash/reading-permission-strings) then showed a file nobody was allowed to write to being deleted without difficulty. All four are the same gap, and this chapter closes it with one idea: a file and its name are separate things, and the name is the less important of the two.

Intermediate16 min readLinuxPart IFundamentalsFilesystemMental Model

Part I · Module 6 · Chapter 6.1 · Names, Inodes and What a Directory Really Contains

1. The Thing Everyone Assumes

The natural picture is that a directory contains files, the way a box contains objects. Move the file and it leaves the box; delete the box and the files inside go with it.

That picture is wrong in one specific way, and the way it is wrong explains everything in this module.

A directory does not contain files. It contains names, and each name is paired with a number that identifies something stored elsewhere. The file itself is not in the directory at all.

Once that separation is in place, four things that looked arbitrary become obvious consequences.

2. Three Things, Not One

What people call "a file" is really three separate things:

The thing	What it is	Where it lives
the name	text like `data.txt`	an entry in a directory
the inode	the file's identity and properties	the filesystem's own table
the contents	the actual bytes	somewhere on the disk

Figure 1 — the name, the inode and the contents. The name is an entry in a directory and points at an inode by number. The inode holds everything Chapter 2.5's long listing showed you except the name itself. Two names can point at the same inode, which is drawn here because it is the normal arrangement rather than an exotic one — and it is why the inode has to count how many names refer to it.

The word inode is short for index node. It is not a word you need to love; it is the name for the record that holds a file's identity.

What is striking is what the inode holds, which is everything Chapter 2.5's long listing showed you except the name:

Azvya Education Pvt. Ltd.VLSI Mentor

ls -l, sorted by where each field actually lives

-rw-r--r--  1  engineer  engineer  482  Mar 28 09:12  data.txt
│           │  │         │         │    │             └── in the DIRECTORY
└───────────┴──┴─────────┴─────────┴────┴──────────────── in the INODE

Type, permissions, link count, owner, group, size and timestamp are all properties of the file. Only the name belongs to the directory.

3. Seeing the Inode Number

Each inode has a number, unique within its filesystem. ls -i shows it:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -i data.txt
83083997 data.txt

That number is the file's real identity on that filesystem. The name data.txt is a label somebody attached to it.

Combined with the long listing, which is how you will usually want it:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -li data.txt
83083997 -rw-r--r-- 1 engineer engineer 9 Mar 28 09:12 data.txt

Chapter 2.5's fields, now with the inode number in front. Note the order: inode, mode, link count, owner, group, size, date, name. The link count is the third field, and §5 is finally about to explain it.

4. What an Entry Actually Is

Now Chapter 2.1's sentence can be finished. A directory is a list, and each item in the list is a pair:

Azvya Education Pvt. Ltd.VLSI Mentor

What a directory holds

   name              inode number
   ─────────────     ────────────
   .                 83083900
   ..                83083888
   data.txt          83083997
   notes.txt         83084010
   rtl               83084055

That is it. No contents, no permissions, no sizes — those are all in the inodes that the numbers point at.

Two things fall out immediately.

. and .. are ordinary entries. Chapter 2.3 insisted they were real, and here they are: two names like any other, pointing at this directory and at its parent. Nothing special, and that is why they appear in ls -a and why they work identically in every program.

Renaming is cheap. Chapter 3.2 said that mv within one filesystem is instant however large the file. Now you can see why: renaming changes the text in a directory entry. The inode is untouched and the contents are not moved at all.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -i report.txt
83084010 report.txt

$ mv report.txt final_report.txt

$ ls -i final_report.txt
83084010 final_report.txt

Same inode. The file never moved; a label changed.

5. The Link Count, Explained at Last

Chapter 2.5 introduced the third field and deferred it. It is this:

The link count is the number of names that point at this inode.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -li data.txt
83083997 -rw-r--r-- 1 engineer engineer 9 Mar 28 09:12 data.txt
                    ↑

One name points at inode 83083997. The ordinary case.

The count exists because of a question the system has to be able to answer: when is it safe to free the contents? Not when a name is removed — another name might still refer to them. Only when the last name is gone.

So the rule, which is the whole of Chapter 3.3's mechanism:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

removing a name  →  decrement the count
count reaches 0  →  the contents can be released
count above 0    →  the contents stay, reachable by the other names

Chapter 3.3 said rm "removes an entry from a directory" and that the data becomes unreachable "when the last name pointing at a file is gone". That sentence was precise; this is the machinery under it.

Why directories have larger counts

Chapter 2.5 noticed that directories show counts above 1 and gave the arithmetic. Here is the reason.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ mkdir lc
$ ls -ld lc
drwxr-xr-x 2 engineer engineer 4096 Mar 28 10:00 lc

Two names already point at this brand-new, empty directory:

lc, the entry in its parent;
., the entry inside lc that points at lc itself.

Add a subdirectory and a third appears:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ mkdir lc/sub
$ ls -ld lc
drwxr-xr-x 3 engineer engineer 4096 Mar 28 10:01 lc

The third is .. inside sub, which points back at lc. Each subdirectory adds exactly one, which gives the rule from Chapter 2.5:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

a directory's link count  =  2  +  the number of subdirectories

Note what is not counted: ordinary files inside. A file's entry points at the file's own inode, not at the directory's. So a directory with fifty files and no subdirectories still shows 2.

6. The Four Puzzles, Resolved

Everything this chapter was built to explain, now explainable.

Why is deleting called "removing a name"? Because that is the only thing rm does to the directory. The contents are released as a consequence, and only if no other name remains.

Why can a read-only file be deleted? Chapter 5.2's demonstration. Deleting modifies the directory's list of names, which needs write permission on the directory. The file's own permissions govern the file's contents, and the contents are not what is being changed.

Why does the link count exist at all? §5. Something has to know when the last name is gone.

Why is renaming instant on a huge file? §4. Only the text of an entry changes.

Each of those was stated as a rule in an earlier chapter and had to be taken on trust. None of them needs to be memorised now — they all follow from Figure 1.

7. Using Inode Numbers in Practice

Three things the number is actually good for.

Telling whether two paths are the same file.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -i /usr/bin/python3 /usr/bin/python3.11
 1572874 /usr/bin/python3
 1572874 /usr/bin/python3.11

Same number, same filesystem, therefore the same file under two names. Two different numbers would mean two separate files that happen to have similar names — a genuinely useful distinction when you are working out which of several similarly named tools you are actually running.

Noticing that a file has been replaced rather than edited.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

$ ls -i config.txt
83084010 config.txt

# ... some time later ...

$ ls -i config.txt
83084999 config.txt

A different inode under the same name means this is not the same file any more — something removed the old one and created a new one rather than editing in place. Many editors and tools work that way, and it explains Chapter 4.4's log-rotation problem: tail -f was holding the old inode while the name had been attached to a new one.

Deleting a file whose name is unusable. Chapter 3.4 covered names with awkward characters. When a name is so strange that you cannot type it reliably, the inode number gives a way to identify the file precisely — through find, which is Module 14 and takes an inode number as a search criterion.

8. Why This Matters in Engineering Work

Shared release trees are built on this. Large projects often publish a release as a tree where many paths point at the same underlying files, so that a dozen revisions do not take a dozen times the space. That arrangement only makes sense if you know that a name and a file are separate — otherwise the disk usage looks impossible.

"The file changed but my tool did not notice." Chapter 4.4's rotation problem in general form. A program that opened a file holds the inode, not the name, so replacing the file under the name leaves the program reading something nobody else can see. The inode number is how you confirm that is what happened.

Disk space that does not add up. If removing a large file frees nothing, some other name — or some running program — is still holding the inode. The count in ls -l is the first place to look, and the explanation is always §5.

Part II meets all three in real project areas.

9. Practice

Question 1. Name the three separate things that make up what people casually call "a file", and say where each one lives.

Question 2. Which fields of ls -l live in the inode, and which lives in the directory?

Question 3. What exactly does a directory entry contain?

Question 4. What does the link count count? Give the rule for when a file's contents are released.

Question 5. A brand-new empty directory has a link count of 2. Name both names that point at it.

Question 6. You add four subdirectories and six files to that directory. What is the link count on a typical Linux filesystem, and why do the files not affect it?

Question 7. Two paths show the same inode number. Under what condition does that prove they are the same file?

Question 8. You run ls -i config.txt twice, an hour apart, and get different numbers. What happened, and which earlier chapter's problem does this explain?

Question 9. Explain, using this chapter's model, why a file with mode r--r--r-- can be deleted from a directory you can write to.

Question 10. Why is mv bigfile.dat newname.dat instant even on a 50 GB file?

Answers

1. The name, which lives in a directory. The inode, which lives in the filesystem's inode table and holds the metadata. The contents, which live in data blocks on the device. Separating them is what makes everything else in this module explicable.

2. Almost all of them live in the inode: the type and permissions, the link count, the owner, the group, the size, and the timestamps. Only the name comes from the directory. That is why ls -l has to read two different places to print one line.

3. A directory entry contains just two things: a name and the inode number it refers to. Nothing else — not the size, not the permissions, not the owner. A directory is a lookup table from names to inode numbers.

4. It counts the number of names (directory entries) that refer to that inode. The contents are released when the link count reaches zero and no process still has the file open — both conditions, which is why deleting a file that a running program is writing to does not free the space until that program exits.

5. Its own . entry, and its name in its parent directory. Both are real directory entries pointing at the same inode, which is why the count starts at 2 rather than 1.

6. 6 — the original 2 plus one for each of the four subdirectories, each contributing through its own .. entry. The files do not affect it because a file's name in this directory is a link to the file's inode, not to the directory's. Worth knowing as a portability point: this is the behaviour of typical Linux filesystems such as ext4 and xfs. Not every filesystem does it this way — on macOS's APFS the count tracks every entry, files included — so the rule is a useful Linux heuristic rather than a universal law.

7. Only if the two paths are on the same filesystem. Inode numbers are unique within a filesystem, not across the machine, so two files on different devices can share a number by coincidence. ls -i alone is therefore not proof; you need the device too, which is what stat reports and what find -samefile uses.

8. The file was replaced rather than modified — something wrote a new file and moved it into place, so the name now refers to a different inode. This explains Chapter 4.4's problem: tail -f holds the old inode open and keeps reading a file nothing writes to any more, which is why it goes silent after a log rotation.

9. Because deleting is removing a name from a directory, and that is a modification of the directory, governed by the directory's write permission. The file's own r--r--r-- governs its contents — reading and writing them — and is never consulted when a name is unlinked. Two different objects, two different permission checks.

10. Because within one filesystem mv only changes the name: it removes one directory entry and adds another, both pointing at the same inode. The 50 GB of contents are not touched and do not move. (Across filesystems there is no shared inode table, so mv has to copy every byte and then delete the original — which is why the same command can be instant one day and slow the next.)

10. Remember

A directory contains names, not files. Each entry is a name paired with an inode number.
Three separate things: the name in a directory, the inode holding the file's identity and properties, and the contents on disk.
The inode holds everything ls -l shows except the name — type, permissions, link count, owner, group, size, timestamp.
A file does not know its own name, which is what makes several names for one file possible.
ls -i shows the inode number; ls -li adds it to the long listing. The number identifies the file within its filesystem.
. and .. are ordinary entries — names pointing at this directory and its parent.
The link count is how many names point at this inode. Contents are released only when it reaches zero.
A directory's count is 2 plus its subdirectories on common Linux filesystems — its own entry, its ., and one .. per subdirectory. Files inside do not count, and some filesystems count differently.
Renaming is instant because only the text of an entry changes.
Same inode plus same filesystem means the same file. Chapter 23.2 uses the same identity test to tell authored source from a generated copy. A changed inode under an unchanged name means the file was replaced, not edited.

The model is now complete enough to do something with. The next chapter gives one file a second name deliberately — and shows that neither name is the original.

Where this fits

Part of the Linux & Bash curriculum.