HTML rendering created 2025-09-06 byMichael Kerrisk, author ofThe Linux Programming Interface. For details of in-depthLinux/UNIX system programming training courses that I teach, lookhere. Hosting byjambit GmbH. |  |
NAME |DESCRIPTION |STANDARDS |HISTORY |NOTES |SEE ALSO |COLOPHON | |
inode(7) Miscellaneous Information Manualinode(7)inode - file inode information
Each file has an inode containing metadata about the file. An application can retrieve this metadata usingstat(2) (or related calls), which returns astat structure, orstatx(2), which returns astatx structure. The following is a list of the information typically found in, or associated with, the file inode, with the names of the corresponding structure fields returned bystat(2) andstatx(2): Device where inode residesstat.st_dev;statx.stx_dev_minor andstatx.stx_dev_major Each inode (as well as the associated file) resides in a filesystem that is hosted on a device. That device is identified by the combination of its major ID (which identifies the general class of device) and minor ID (which identifies a specific instance in the general class). Inode numberstat.st_ino;statx.stx_ino Each file in a filesystem has a unique inode number. Inode numbers are guaranteed to be unique only within a filesystem (i.e., the same inode numbers may be used by different filesystems, which is the reason that hard links may not cross filesystem boundaries). This field contains the file's inode number. File type and modestat.st_mode;statx.stx_mode See the discussion of file type and mode, below. Link countstat.st_nlink;statx.stx_nlink This field contains the number of hard links to the file. Additional links to an existing file are created usinglink(2). User IDstat.st_uid;statx.stx_uid This field records the user ID of the owner of the file. For newly created files, the file user ID is the effective user ID of the creating process. The user ID of a file can be changed usingchown(2). Group IDstat.st_gid;statx.stx_gid The inode records the ID of the group owner of the file. For newly created files, the file group ID is either the group ID of the parent directory or the effective group ID of the creating process, depending on whether or not the set-group-ID bit is set on the parent directory (see below). The group ID of a file can be changed usingchown(2). Device represented by this inodestat.st_rdev;statx.stx_rdev_minor andstatx.stx_rdev_major If this file (inode) represents a device, then the inode records the major and minor ID of that device. File sizestat.st_size;statx.stx_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. Preferred block size for I/Ostat.st_blksize;statx.stx_blksize This field gives the "preferred" blocksize for efficient filesystem I/O. (Writing to a file in smaller chunks may cause an inefficient read-modify-rewrite.) Number of blocks allocated to the filestat.st_blocks;statx.stx_blocks This field indicates the number of blocks allocated to the file, 512-byte units, (This may be smaller thanst_size/512 when the file has holes.) The POSIX.1 standard notes that the unit for thest_blocks member of thestat structure is not defined by the standard. On many implementations it is 512 bytes; on a few systems, a different unit is used, such as 1024. Furthermore, the unit may differ on a per-filesystem basis. Last access timestamp (atime)stat.st_atime;statx.stx_atime This is the file's last access timestamp. It is changed by file accesses, for example, byexecve(2),mknod(2),pipe(2),utime(2), andread(2) (of more than zero bytes). Other interfaces, such asmmap(2), may or may not update the atime timestamp Some filesystem types allow mounting in such a way that file and/or directory accesses do not cause an update of the atime timestamp. (Seenoatime,nodiratime, andrelatime inmount(8), and related information inmount(2).) In addition, the atime timestamp is not updated if a file is opened with theO_NOATIMEflag; seeopen(2). File creation (birth) timestamp (btime) (not returned in thestat structure);statx.stx_btime The file's creation timestamp. This is set on file creation and not changed subsequently. The btime timestamp was not historically present on UNIX systems and is not currently supported by most Linux filesystems. Last modification timestamp (mtime)stat.st_mtime;statx.stx_mtime This is the file's last modification timestamp. It is changed by file modifications, for example, bymknod(2),truncate(2),utime(2), andwrite(2) (of more than zero bytes). Moreover, the mtime timestamp of a directory is changed by the creation or deletion of files in that directory. The mtime timestamp isnot changed for changes in owner, group, hard link count, or mode. Last status change timestamp (ctime)stat.st_ctime;statx.stx_ctime This is the file's last status change timestamp. It is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.). The timestamp fields report time measured with a zero point at theEpoch, 1970-01-01 00:00:00 +0000, UTC (seetime(7)). Nanosecond timestamps are supported on XFS, JFS, Btrfs, and ext4 (since Linux 2.6.23). Nanosecond timestamps are not supported in ext2, ext3, and Reiserfs. In order to return timestamps with nanosecond precision, the timestamp fields in thestat andstatx structures are defined as structures that include a nanosecond component. Seestat(2) andstatx(2) for details. On filesystems that do not support subsecond timestamps, the nanosecond fields in thestat andstatx structures are returned with the value 0.The file type and mode Thestat.st_mode field (forstatx(2), thestatx.stx_mode field) contains the file type and mode. POSIX refers to thestat.st_mode bits corresponding to the maskS_IFMT(see below) as thefile type, the 12 bits corresponding to the mask 07777 as thefile mode bits and the least significant 9 bits (0777) as thefile permission bits. The following mask values are defined for the file type:S_IFMT0170000 bit mask for the file type bit fieldS_IFSOCK0140000 socketS_IFLNK0120000 symbolic linkS_IFREG0100000 regular fileS_IFBLK0060000 block deviceS_IFDIR0040000 directoryS_IFCHR0020000 character deviceS_IFIFO0010000 FIFO Thus, to test for a regular file (for example), one could write: stat(pathname, &sb); if ((sb.st_mode & S_IFMT) == S_IFREG) { /* Handle regular file */ } Because tests of the above form are common, additional macros are defined by POSIX to allow the test of the file type inst_mode to be written more concisely: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.) The preceding code snippet could thus be rewritten as: stat(pathname, &sb); if (S_ISREG(sb.st_mode)) { /* Handle regular file */ } 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 exceptS_IFSOCKandS_ISSOCK() are provided if_XOPEN_SOURCEis defined. The definition ofS_IFSOCKcan also be exposed either by defining_XOPEN_SOURCEwith a value of 500 or greater or (since glibc 2.24) by defining both_XOPEN_SOURCEand_XOPEN_SOURCE_EXTENDED. The definition ofS_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_SOURCEwith a value of 200112L or greater, or (since glibc 2.24) by defining both_XOPEN_SOURCEand_XOPEN_SOURCE_EXTENDED. The following mask values are defined for the file mode component of thest_mode field:S_ISUID04000 set-user-ID bit (seeexecve(2))S_ISGID02000 set-group-ID bit (see below)S_ISVTX01000 sticky bit (see below)S_IRWXU00700 owner has read, write, and execute permissionS_IRUSR00400 owner has read permissionS_IWUSR00200 owner has write permissionS_IXUSR00100 owner has execute permissionS_IRWXG00070 group has read, write, and execute permissionS_IRGRP00040 group has read permissionS_IWGRP00020 group has write permissionS_IXGRP00010 group has execute permissionS_IRWXO00007 others (not in group) have read, write, and execute permissionS_IROTH00004 others have read permissionS_IWOTH00002 others have write permissionS_IXOTH00001 others have execute permission The set-group-ID bit (S_ISGID) has several special uses. 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 theS_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 inexecve(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. 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.POSIX.1-2008.
POSIX.1-2001. POSIX.1-1990 did not describe theS_IFMT,S_IFSOCK,S_IFLNK,S_IFREG,S_IFBLK,S_IFDIR,S_IFCHR,S_IFIFO, andS_ISVTX constants, but instead specified the use of the macrosS_ISDIR() and so on. TheS_ISLNK() andS_ISSOCK() macros were not in POSIX.1-1996; the former is from SVID 4, the latter from SUSv2. UNIX V7 (and later systems) hadS_IREAD,S_IWRITE,S_IEXEC, and where POSIX prescribes the synonymsS_IRUSR,S_IWUSR, andS_IXUSR.
For pseudofiles that are autogenerated by the kernel, the file size (stat.st_size;statx.stx_size) reported by the kernel is not accurate. 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. 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).
stat(1),stat(2),statx(2),symlink(7)
This page is part of theman-pages (Linux kernel and C library user-space interface documentation) project. Information about the project can be found at ⟨https://www.kernel.org/doc/man-pages/⟩. If you have a bug report for this manual page, see ⟨https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING⟩. This page was obtained from the tarball man-pages-6.15.tar.gz fetched from ⟨https://mirrors.edge.kernel.org/pub/linux/docs/man-pages/⟩ on 2025-08-11. If you discover any rendering problems in this HTML version of the page, or you believe there is a better or more up- to-date source for the page, or you have corrections or improvements to the information in this COLOPHON (which isnot part of the original manual page), send a mail to man-pages@man7.orgLinux man-pages 6.15 2025-05-17inode(7)Pages that refer to this page:systemd-vpick(1), chmod(2), fsync(2), getdents(2), mkdir(2), mknod(2), open(2), stat(2), statx(2), truncate(2), umask(2), utime(2), utimensat(2), stat(3type), systemd.exec(5), symlink(7)
HTML rendering created 2025-09-06 byMichael Kerrisk, author ofThe Linux Programming Interface. For details of in-depthLinux/UNIX system programming training courses that I teach, lookhere. Hosting byjambit GmbH. | |