Learn › Linux Foundations › Reading Files
stat - a hands-on Linux lab on a real virtual machine.
Pull a file's record card with stat: the exact Size in bytes, owner, permissions, inode, and the three timestamps, plus cards for binaries and folders. stat is structure-only: inode numbers and dates vary per machine, so the drills teach the card's shape and the fields that never lie.
This module has been about reading what is inside files: printing them, slicing them, paging them, counting them. Now stand back for a moment, because some questions no amount of reading answers. Who owns the boot log? When did it last change? May you even write to it? You could stare at all eight lines of logs/messages.log forever and never know.
The filesystem knows. For every file on the disk it keeps a written record ABOUT the file, separate from the contents. One command prints that record, and it is the only command in this lesson: stat.
There is also a score to settle. In the wc lesson, intel/notes.md swore it had zero lines, even though you could plainly read text in it. Two tools told two stories about one file. Today you meet the referee.
The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. stat only ever reads a file's record; it cannot change, move, or delete anything. You are standing in the intercept folder, the same captured logs, intel notes, and binaries this whole module works on.
stat is short for status. Point it at a file and it prints the file's metadata: the information the filesystem records ABOUT the file, as opposed to the words stored inside it. Think of a library card taped inside a book's cover. The card does not retell the story. It records the book's size, its owner, and the dates it was handled.
stat has printed this record since the earliest days of Unix in the 1970s, and you have already seen its work secondhand. Remember ls -l from the ls lesson? Every column of that long listing, the sizes, owners, dates, and permissions, comes from this same record. ls -l shows a one-line summary. stat hands you the whole card.
Time to see one. You will run stat on the boot log, logs/messages.log. Before you run it, decide one thing. Remember from the wc lesson: wc measured this exact file at 8 lines, 35 words, 208 bytes. If stat really is the file's official record, that 208 must appear somewhere on the card. Watch for where.
stat logs/messages.log
prompt: student@linuxcamp:~/intercept$ answer: stat logs/messages.log output: File: logs/messages.log Size: 208 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 131074 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/student) Gid: ( 1000/student) Access: 2026-07-01 12:00:04.000000000 +0000 Modify: 2026-07-01 12:00:00.000000000 +0000 Change: 2026-07-01 12:00:00.000000000 +0000 hint: Type stat, a space, then the path to the file: stat logs/messages.log
Almost every value on this card belongs to one machine and one moment. The inode number, the device id, and all three dates will read differently on your live machine, because this card is one real capture kept as the example. What never varies is the card's SHAPE. And one value is always the file's own: Size, which here reads 208, the very byte count wc gave you.
There it is, second line, first field: Size: 208. The filesystem agrees with wc to the byte. Seven lines came back in all. Each answers a different question: what the file is called, how big it is, where it lives, who owns it, and when it was touched. The next two steps read the card line by line.
Here is the record card as a labeled map. Each row names one field from the card, top to bottom, and tells you what it records:
One quiet detail rewards a second look. Blocks: 8 times 512 bytes per slot is 4096 bytes. Disks hand out space in fixed chunks, so even this 208-byte file occupies one full 4096-byte chunk. The very next lesson, du, builds a whole tool out of that fact.
An inode is the filesystem's ID number for a file, the way a catalog number identifies a book no matter what title is on the spine. You only need the idea for now. It returns, along with Links, when you reach the ln lesson later in the track. The permission code 0644/-rw-r--r-- also gets its own lesson; for now, read it as "who may do what."
The card ends with three dated lines, and most engineers mix them up at first. Keep the library card in mind: a book can be borrowed, rewritten, or have its card corrected, and those are three different events.
Modify is the one you will reach for most. "When did this log last get written to?" is a Modify question. The trap is Change: it does NOT mean the contents changed. Renaming a file rewrites its card, so Change moves while Modify stands still.
On some machines the card carries a fourth line, Birth, the moment the file was created. Older filesystems cannot record it and print a dash there instead. And do not be surprised that even READING a file can move its Access date forward: reading is an event the filesystem may note on the card.
Now settle the score from the wc lesson. wc -l intel/notes.md reported 0, zero lines, even though the file plainly holds a note. The file lesson added its clue: notes.md has "no line terminators," meaning no final newline character.
Pull the record card and let the filesystem rule. Before you run it, commit to an answer: will Size read 0, the way wc -l did?
stat intel/notes.md
prompt: student@linuxcamp:~/intercept$ answer: stat intel/notes.md output: File: intel/notes.md Size: 35 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 131079 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/student) Gid: ( 1000/student) Access: 2026-07-01 12:00:04.000000000 +0000 Modify: 2026-07-01 12:00:00.000000000 +0000 Change: 2026-07-01 12:00:00.000000000 +0000 hint: Same shape as before, new path: stat intel/notes.md
Size: 35. Not zero, not close to zero. Here is the verdict: wc -l counts FINISHED lines, ones sealed with a newline character, and this file's single line was never sealed. stat counts bytes, and there are 35 real bytes of text in there. The file was never empty. One tool was simply answering a narrower question than you thought.
That is a milestone worth naming. Two commands disagreed about a file, and instead of guessing, you pulled the filesystem's own record and settled it. Reading the card when the tools seem to argue is exactly what stat is for. As before, your inode and dates will differ on the live machine; Size is the field you can trust anywhere.
stat happily takes more than one name at a time. Before you run the next command, decide what the output will look like: will stat squeeze each file onto a single line, or print one full card per file?
stat logs/messages.log intel/notes.md
prompt: student@linuxcamp:~/intercept$ answer: stat logs/messages.log intel/notes.md output: File: logs/messages.log Size: 208 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 131074 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/student) Gid: ( 1000/student) Access: 2026-07-01 12:00:04.000000000 +0000 Modify: 2026-07-01 12:00:00.000000000 +0000 Change: 2026-07-01 12:00:00.000000000 +0000 File: intel/notes.md Size: 35 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 131079 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/student) Gid: ( 1000/student) Access: 2026-07-01 12:00:04.000000000 +0000 Modify: 2026-07-01 12:00:00.000000000 +0000 Change: 2026-07-01 12:00:00.000000000 +0000 hint: Give stat both paths, separated by a space: stat logs/messages.log intel/notes.md
One full card per file, stacked in the order you named them, each starting with its own File: line. No shortening, no summary. Stacked cards make comparison easy: Size: 208 against Size: 35 in a single glance, without running the command twice.
Scaffolding off. No command is shown from here on. You have every piece you need.
In binaries/ sits payload.bin, one of the two raw captures on this station. The intercept work order lists it at exactly 32 bytes. Pull its record card and check whether the filesystem's official record agrees with the work order.
prompt: student@linuxcamp:~/intercept$ answer: stat binaries/payload.bin output: File: binaries/payload.bin Size: 32 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 131082 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/student) Gid: ( 1000/student) Access: 2026-07-01 12:00:04.000000000 +0000 Modify: 2026-07-01 12:00:00.000000000 +0000 Change: 2026-07-01 12:00:00.000000000 +0000 hint: This lesson has exactly one command, and the file sits inside the binaries folder.
Size: 32, just as the work order claimed. Notice what did NOT happen: no unreadable bytes sprayed across your screen. stat reads the card, never the contents, so it is always safe to run on a binary file. Remember the file lesson's advice about checking before you cat a mystery file? stat is just as safe a first move, and to the filesystem this card looks exactly like a text file's card, because bytes are bytes.
One more, and it is the strangest card on the station. In Linux, a folder has a record card of its very own. Pull the card for logs itself, the folder, not any file inside it. Before you run it, decide: which word will replace regular file on the card?
prompt: student@linuxcamp:~/intercept$ answer: stat logs output: File: logs Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fd00h/64768d Inode: 131073 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 1000/student) Gid: ( 1000/student) Access: 2026-07-01 12:00:04.000000000 +0000 Modify: 2026-07-01 12:00:00.000000000 +0000 Change: 2026-07-01 12:00:00.000000000 +0000 hint: Point the command at the folder's bare name, nothing else.
Line two now ends in directory, and the permission code starts with a d for the same reason. Two more details reward a close look. Size: 4096 is NOT the size of the files inside; it is the size of the folder's own list of names, one disk chunk. Measuring what is inside a folder is a different job, and the next two lessons, du and df, hand you the tools. And Links: 2 instead of 1 is a directory quirk the ln lesson will explain. You recalled the command and read an unfamiliar card without help, which is exactly what the real machine will ask of you.
You earned this cheat sheet. Every form on it is one you have already run on the intercept fixture:
And the card itself, the part worth keeping:
When two tools seem to disagree about a file, or a file behaves strangely, pull the card. stat is the referee: the filesystem's own record, straight from the source.
The commands of this module chain naturally. file tells you what a thing is. stat tells you how big it is and who owns it, without touching the contents. Then you pick the reader you already know, cat, head, tail, or less, with no surprises waiting.
One line to file away for later: stat also has a -c flag that prints a single chosen field instead of the whole card, which scripts love. You do not need it yet. The full card is the lesson.
The practice terminal has shown you the whole record card. You can now read a Size you can trust anywhere, the inode and dates that belong to each machine, and three clocks with three meanings. You pulled cards for text files, binaries, and a folder, every one of them yourself.
The Reading Files module ends with one real Linux machine, the reading-files capstone mission, and that is where you run stat for real. A VM boots just for you with the same intercept fixture: the logs, the intel notes, the two binary captures. This time the values on every card are your machine's own, live inode numbers and real timestamps included. One difference from here: the mission shows no commands. You read the objective, recall the command, type it. That recall is what makes it stick.
Finish the remaining Reading Files lessons, then go pull the real cards.
Practice stat in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.