stat(3type)

✨ stat(3type) ✨

okay bestie, gather round 💖 you're reading a page from the 3type manual — that's the section where the Linux man-pages just... describe a type to you. No commands, no vibes-and-prayers, just "here is the shape of a thing, memorize it, it's on the test." And this particular thing? It's stat, the file status struct. It's giving main character energy. Let's go 🫶

---

🌸 NAME 🌸

stat — file status. that's it, that's the name, she's simple and iconic 💅

---

📚 LIBRARY 📚

Standard C library (libc) — your girl lives in libc, no extra deps, no cap ✨

---

🎀 SYNOPSIS 🎀

#include <sys/stat.h>

struct stat {
    dev_t      st_dev;      /* ID of device containing file */
    ino_t      st_ino;      /* Inode number */
    mode_t     st_mode;     /* File type and mode */
    nlink_t    st_nlink;    /* Number of hard links */
    uid_t      st_uid;      /* User ID of owner */
    gid_t      st_gid;      /* Group ID of owner */
    dev_t      st_rdev;     /* Device ID (if special file) */
    off_t      st_size;     /* Total size, in bytes */
    blksize_t  st_blksize;  /* Block size for filesystem I/O */
    blkcnt_t   st_blocks;   /* Number of 512 B blocks allocated */

    /* Since POSIX.1-2008, this structure supports nanosecond
       precision for the following timestamp fields.
       For the details before POSIX.1-2008, see HISTORY.  */

    struct timespec  st_atim;  /* Time of last access */
    struct timespec  st_mtim;  /* Time of last modification */
    struct timespec  st_ctim;  /* Time of last status change */

#define st_atime  st_atim.tv_sec  /* Backward compatibility */
#define st_mtime  st_mtim.tv_sec
#define st_ctime  st_ctim.tv_sec
};

🧚 Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

.st_atim, .st_mtim, .st_ctim:
    Since glibc 2.12:
        _POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700
    glibc 2.19 and earlier:
        _BSD_SOURCE || _SVID_SOURCE

---

💖 DESCRIPTION 💖

Describes information about a file. literally just. here's what a file is, in numbers 🫶

The fields are as follows:

• .st_dev — this field describes the device on which this file resides. (the major(3) and minor(3) macros may be useful to decompose the device ID in this field.)
• .st_ino — this field contains the file's inode number in the filesystem on .st_dev. If stat(2) was called on the mount point, then .st_ino differs from .d_ino returned by readdir(3) for the corresponding directory entry in the parent directory. In this case, .st_ino is the inode number of the root directory of the mounted filesystem, while .d_ino is the inode number of the mount point in the parent filesystem. (yes this trips everyone up, no you're not dumb 🌸)
• .st_mode — this field contains the file type and mode. See inode(7) for further information.
• .st_nlink — this field contains the number of hard links to the file.
• .st_uid — this field contains the user ID of the owner of the file.
• .st_gid — this field contains the ID of the group owner of the file.
• .st_rdev — this field describes the device that this file (inode) represents.
• .st_size — this field gives the size of the file (if it is a regular file or a symbolic link) in bytes. The size of a symbolic link is the length of the pathname it contains, without a terminating null byte.
• .st_blksize — this field gives the "preferred" block size for efficient filesystem I/O.
• .st_blocks — this field indicates the number of blocks allocated to the file, in 512-byte units. (This may be smaller than .st_size/512 when the file has holes.) 💀
• .st_atime — this is the time of the last access of file data.
• .st_mtime — this is the time of last modification of file data.
• .st_ctime — this is the file's last status change timestamp (time of last change to the inode).

For further information on the above fields, see inode(7). go read it, bestie, it's the lore 🦋

---

👑 STANDARDS 👑

POSIX.1-2024. periodt.

---

🌈 HISTORY 🌈

stat — POSIX.1-1988. ancient. vintage. ate and left no crumbs.

.st_rdev .st_blksize .st_blocks — SUSv1, POSIX.1-2001 XSI.

Initially, SUSv1 specified .st_blksize and .st_blocks with type long. This was remedied in SUSv2. (they fixed it, slay 🔥)

Old kernels and old standards did not support nanosecond timestamp fields. Instead, there were three timestamp fields —.st_atime, .st_mtime, and .st_ctime— typed as time_t that recorded timestamps with one-second precision. one. whole. second. 💀 imagine.

Since Linux 2.5.48, the stat structure supports nanosecond resolution for the three file timestamp fields. The nanosecond components of each timestamp are available via names of the form .st_atim.tv_nsec, if suitable test macros are defined. Nanosecond timestamps were standardized in POSIX.1-2008, and, starting with glibc 2.12, glibc exposes the nanosecond component names if _POSIX_C_SOURCE is defined with the value 200809L or greater, or _XOPEN_SOURCE is defined with the value 700 or greater. Up to and including glibc 2.19, the definitions of the nanoseconds components are also defined if _BSD_SOURCE or _SVID_SOURCE is defined. If none of the aforementioned macros are defined, then the nanosecond values are exposed with names of the form .st_atimensec. (the way that these macros gate your fields is genuinely so unserious 🎀)

---

📝 NOTES 📝

The following header also provides this type: <ftw.h>. surprise bonus header, iykyk ✨

---

🔍 SEE ALSO 🔍

stat(2), inode(7)

---

fr fr that's the whole page, no skips, no summarising, every field came to the function 🙈

okay byeeee — this cutie of a page is from Linux man-pages 6.20, dated 2026-02-08. eat it up bestie 💅💖🌸