inode(7)

💖 inode(7) — file inode information 💖

okay so bestie, welcome to the glow-up. this page lives in the Miscellaneous Information Manual, it's page inode in section 7, and it is literally all about file inode information. no cap, that's the whole name section, we move 🫶

---

✨ DESCRIPTION ✨

so. every single file has an inode, and the inode is out here holding all the metadata about that file. it's giving backstage pass energy tbh 🎀

and like, how do you even see that metadata? you call stat(2) (or its related calls, they're all besties), which hands you back a stat structure — OR you call statx(2), which hands you back a statx structure. two icons, two structures, same vibe check 💅

here's the rundown of the info that typically lives in (or is associated with) the file inode, and the names of the matching structure fields you get back from stat(2) and statx(2). buckle up, it's a long list and every single one matters:

---

📱 Device where inode resides

stat.st_dev; statx.stx_dev_minor and statx.stx_dev_major

every inode (and, like, the file attached to it) resides in a filesystem, and that filesystem is hosted on a device. that device gets identified by the combo of its major ID (which tells you the general class of device) and its minor ID (which tells you which specific instance in that general class). it's like area code plus phone number, iykyk ✨

🔢 Inode number

stat.st_ino; statx.stx_ino

every file in a filesystem has a unique inode number. and bestie, "unique" here comes with a tiny asterisk: inode numbers are guaranteed unique only within a filesystem. which means different filesystems can totally reuse the same inode numbers — and that is exactly the reason hard links may not cross filesystem boundaries 😭. this field holds the file's inode number, periodt.

🏷️ File type and mode

stat.st_mode; statx.stx_mode

see the discussion of file type and mode, down below 👇 (it gets its own whole subsection, she's the main character)

🔗 Link count

stat.st_nlink; statx.stx_nlink

this field is the number of hard links to the file. wanna add more links to a file that already exists? that's link(2)'s whole job 💜

👤 User ID

stat.st_uid; statx.stx_uid

this one records the user ID of the file's owner. for brand-new files, the file user ID is the effective user ID of the process that created it. and you can change a file's user ID with chown(2) — yes, that chown, the one you're always googling 🌸

👥 Group ID

stat.st_gid; statx.stx_gid

the inode also records the ID of the group owner of the file. for newly created files, that file group ID is either the group ID of the parent directory or the effective group ID of the creating process — and which one you get depends on whether or not the set-group-ID bit is set on the parent directory (see below 👀). group ID of a file can be changed with chown(2), same as above.

🖨️ Device represented by this inode

stat.st_rdev; statx.stx_rdev_minor and statx.stx_rdev_major

if this file (this inode) represents a device, then the inode records the major and minor ID of that device. device-inception, honestly 🦋

📏 File size

stat.st_size; statx.stx_size

this field gives the size of the file in bytes — that's for a regular file or a symbolic link. and for a symlink, the "size" is the length of the pathname it contains, without a terminating null byte.

⚡ Preferred block size for I/O

stat.st_blksize; statx.stx_blksize

this gives the "preferred" blocksize for efficient filesystem I/O. lowkey important warning here: writing to a file in smaller chunks may cause an inefficient read-modify-rewrite. so, you know, chunk responsibly 💅

🧱 Number of blocks allocated to the file

stat.st_blocks; statx.stx_blocks

this field indicates the number of blocks allocated to the file, in 512-byte units. and note: this may be smaller than st_size/512 when the file has holes 🕳️

the POSIX.1 standard notes that the unit for the st_blocks member of the stat structure is not defined by the standard, which is wild but true. on many implementations it's 512 bytes; on a few systems a different unit is used, such as 1024. furthermore, the unit may differ on a per-filesystem basis. so yeah, don't assume, bestie 😭

🕰️ Last access timestamp (atime)

stat.st_atime; statx.stx_atime

this is the file's last access timestamp. it gets changed by file accesses — for example, by execve(2), mknod(2), pipe(2), utime(2), and read(2) (of more than zero bytes). other interfaces, such as mmap(2), may or may not update the atime timestamp. (yes, "may or may not" — she's mysterious like that 🙈)

some filesystem types allow mounting in such a way that file and/or directory accesses do not cause an update of the atime timestamp. (see noatime, nodiratime, and relatime in mount(8), plus related info in mount(2).) on top of that, the atime timestamp is not updated if a file is opened with the O_NOATIME flag; see open(2) 👑

🎂 File creation (birth) timestamp (btime)

(not returned in the stat structure); statx.stx_btime

the file's creation timestamp. it's set on file creation and not changed subsequently. periodt, she's born once and that's it.

and now the sad part: the btime timestamp was not historically present on UNIX systems and is not currently supported by most Linux filesystems. RIP to a real one 💀

✏️ Last modification timestamp (mtime)

stat.st_mtime; statx.stx_mtime

the file's last modification timestamp. it gets changed by file modifications — for example, by mknod(2), truncate(2), utime(2), and write(2) (of more than zero bytes). ALSO, and this one trips people up: the mtime timestamp of a directory is changed by the creation or deletion of files in that directory. but the mtime is not changed for changes in owner, group, hard link count, or mode. those are a whole different timestamp's business, bestie 🎀

🔄 Last status change timestamp (ctime)

stat.st_ctime; statx.stx_ctime

the file's last status change timestamp. it gets changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.). so basically she shows up for both file changes and metadata changes, a true versatile queen 👑

---

so the timestamp fields report time measured with a zero point at the Epoch, 1970-01-01 00:00:00 +0000, UTC (see time(7)). the Epoch. we all start there, spiritually ✨

Nanosecond timestamps are supported on XFS, JFS, Btrfs, and ext4 (since Linux 2.6.23). they are not supported in ext2, ext3, and Reiserfs. and here's how it works internally, bestie: in order to return timestamps with nanosecond precision, the timestamp fields in the stat and statx structures are defined as structures that include a nanosecond component. see stat(2) and statx(2) for the details. and on filesystems that don't support subsecond timestamps, the nanosecond fields in the stat and statx structures come back with the value 0.

---

🎀 The file type and mode 🎀

okay so this is the part everyone actually needs. the stat.st_mode field (for statx(2), that's the statx.stx_mode field) contains the file type and the mode. yes, both, in one field, she's multitasking 💅

POSIX refers to:

• the stat.st_mode bits corresponding to the mask S_IFMT (see below) as the file type
• the 12 bits corresponding to the mask 07777 as the file mode bits
• the least significant 9 bits (0777) as the file permission bits

the following mask values are defined for the file type:

S_IFMT     0170000   bit mask for the file type bit field

S_IFSOCK   0140000   socket
S_IFLNK    0120000   symbolic link
S_IFREG    0100000   regular file
S_IFBLK    0060000   block device
S_IFDIR    0040000   directory
S_IFCHR    0020000   character device
S_IFIFO    0010000   FIFO

so, to test for a regular file (for example), you could write:

stat(pathname, &sb);
if ((sb.st_mode & S_IFMT) == S_IFREG) {
    /* Handle regular file */
}

and listen, because tests like that one are SO common, POSIX also defines extra macros so you can write the file type test on st_mode way more concisely. icons, all of them:

• S_ISREG(m) — is it a regular file? 📄
• S_ISDIR(m) — directory? 📁
• S_ISCHR(m) — character device? 🎛️
• S_ISBLK(m) — block device? 🧱
• S_ISFIFO(m) — FIFO (named pipe)? 🚰
• S_ISLNK(m) — symbolic link? (Not in POSIX.1-1996.) 🔗
• S_ISSOCK(m) — socket? (Not in POSIX.1-1996.) 🧦

so that code snippet from before could be rewritten as:

stat(pathname, &sb);
if (S_ISREG(sb.st_mode)) {
    /* Handle regular file */
}

look at her. cleaner, cuter, slayed ✨

now, the definitions of most of the above file type test macros are provided if any of the following feature test macros is defined: _BSD_SOURCE (in glibc 2.19 and earlier), _SVID_SOURCE (in glibc 2.19 and earlier), or _DEFAULT_SOURCE (in glibc 2.20 and later). in addition, definitions of all of the above macros except S_IFSOCK and S_ISSOCK() are provided if _XOPEN_SOURCE is defined 👀

the definition of S_IFSOCK can also be exposed either by defining _XOPEN_SOURCE with a value of 500 or greater, or (since glibc 2.24) by defining both _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED.

and the definition of S_ISSOCK() is exposed if any of the following feature test macros is defined: _BSD_SOURCE (in glibc 2.19 and earlier), _DEFAULT_SOURCE (in glibc 2.20 and later), _XOPEN_SOURCE with a value of 500 or greater, _POSIX_C_SOURCE with a value of 200112L or greater, or (since glibc 2.24) by defining both _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED. so many options but she's worth it 🫶

---

the following mask values are defined for the file mode component of the st_mode field:

S_ISUID     04000   set-user-ID bit (see execve(2))
S_ISGID     02000   set-group-ID bit (see below)
S_ISVTX     01000   sticky bit (see below)

S_IRWXU     00700   owner has read, write, and execute permission
S_IRUSR     00400   owner has read permission
S_IWUSR     00200   owner has write permission
S_IXUSR     00100   owner has execute permission

S_IRWXG     00070   group has read, write, and execute permission
S_IRGRP     00040   group has read permission
S_IWGRP     00020   group has write permission
S_IXGRP     00010   group has execute permission

S_IRWXO     00007   others (not in group) have read, write, and
                    execute permission
S_IROTH     00004   others have read permission
S_IWOTH     00002   others have write permission
S_IXOTH     00001   others have execute permission

the set-group-ID bit (S_ISGID) has several special uses, bestie, she's booked and busy:

• for a directory, it indicates that BSD semantics are to be used for that directory: files created there inherit their group ID from the directory, not from the effective group ID of the creating process, and directories created there will also get the S_ISGID bit set.
• for an executable file, the set-group-ID bit causes the effective group ID of a process that executes the file to change, as described in execve(2).
• for a file that does not have the group execution bit (S_IXGRP) set, the set-group-ID bit indicates mandatory file/record locking.

and the sticky bit (S_ISVTX) on a directory means that a file in that directory can be renamed or deleted only by the owner of the file, by the owner of the directory, and by a privileged process. it's the "you can't touch my stuff" bit and honestly, iconic 🌈

---

⭐ STANDARDS ⭐

POSIX.1-2008. that's it, that's the standard, periodt.

---

✨ HISTORY ✨

Okay so the lore 💅 — POSIX.1-2001</p> is where this all landed, bestie. But the plot twist? POSIX.1-1990</p> was out here not describing the constants S_IFMT, S_IFSOCK, S_IFLNK, S_IFREG, S_IFBLK, S_IFDIR, S_IFCHR, S_IFIFO, and S_ISVTX at all 🙈 — instead it only specified that you use the macros S_ISDIR() and so on. So like, no constant flexing allowed back then, only macro energy. 😭

And the S_ISLNK() and S_ISSOCK() macros? Not even in POSIX.1-1996, fr fr. The former is from SVID 4, the latter is from SUSv2. Different eras, different vibes, iconic either way. 🫶

Oh and UNIX V7 (and later systems) had S_IREAD, S_IWRITE, S_IEXEC, and where POSIX prescribes the synonyms S_IRUSR, S_IWUSR, and S_IXUSR. Ancient lineage, still serving looks. 👑

---

🌸 NOTES 🌸

Heads up bestie, this one's a real gotcha 💀

For pseudofiles that are autogenerated by the kernel, the file size (stat.st_size; statx.stx_size) reported by the kernel is not accurate. Not "a little off." Not "close enough." Straight up lies. 😭

For example:

• the value 0 is returned for many files under the /proc directory 🙃
• while various files under /sys report a size of 4096 bytes, even though the file content is smaller 🫠

So for such files, one should simply try to read as many bytes as possible (and append '\0' to the returned buffer if it is to be interpreted as a string). That's the move. No cap. ✨

---

💖 SEE ALSO 💖

• stat(1)
• stat(2)
• statx(2)
• symlink(7)

---

and that's a wrap on inode(7), my love 🎀 you now know more about inodes than 99% of people who write code, and that's on periodt.

this page came from Linux man-pages 6.20, dated 2026-02-08 💜 go be the main character of your own filesystem bestie 🌈✨