# inode(7) - man - phpman [INODE(7)](https://www.chedong.com/phpMan.php/man/INODE/7/markdown) Linux Programmer's Manual [INODE(7)](https://www.chedong.com/phpMan.php/man/INODE/7/markdown) ## NAME inode - file inode information ## DESCRIPTION Each file has an inode containing metadata about the file. An application can retrieve this metadata using [**stat**(2)](https://www.chedong.com/phpMan.php/man/stat/2/markdown) (or related calls), which returns a _stat_ structure, or [**statx**(2)](https://www.chedong.com/phpMan.php/man/statx/2/markdown), which returns a _statx_ 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 by [**stat**(2)](https://www.chedong.com/phpMan.php/man/stat/2/markdown) and [**statx**(2)](https://www.chedong.com/phpMan.php/man/statx/2/markdown): Device where inode resides _stat.st_dev_; _statx.stx_dev_minor_ and _statx.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 identi‐ fies the general class of device) and minor ID (which identifies a specific instance in the general class). Inode number _stat.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 dif‐ ferent filesystems, which is the reason that hard links may not cross filesystem boundaries). This field contains the file's inode number. File type and mode _stat.st_mode_; _statx.stx_mode_ See the discussion of file type and mode, below. Link count _stat.st_nlink_; _statx.stx_nlink_ This field contains the number of hard links to the file. Additional links to an ex‐ isting file are created using [**link**(2)](https://www.chedong.com/phpMan.php/man/link/2/markdown). User ID _st_uid_ _stat.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 using [**chown**(2)](https://www.chedong.com/phpMan.php/man/chown/2/markdown). Group ID _stat.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 using [**chown**(2)](https://www.chedong.com/phpMan.php/man/chown/2/markdown). Device represented by this inode _stat.st_rdev_; _statx.stx_rdev_minor_ and _statx.stx_rdev_major_ If this file (inode) represents a device, then the inode records the major and minor ID of that device. File size _stat.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/O _stat.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 file _stat.st_blocks_; _statx.stx_size_ This field indicates the number of blocks allocated to the file, 512-byte units, (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_ struc‐ ture 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 exam‐ ple, by [**execve**(2)](https://www.chedong.com/phpMan.php/man/execve/2/markdown), [**mknod**(2)](https://www.chedong.com/phpMan.php/man/mknod/2/markdown), [**pipe**(2)](https://www.chedong.com/phpMan.php/man/pipe/2/markdown), [**utime**(2)](https://www.chedong.com/phpMan.php/man/utime/2/markdown), and [**read**(2)](https://www.chedong.com/phpMan.php/man/read/2/markdown) (of more than zero bytes). Other interfaces, such as [**mmap**(2)](https://www.chedong.com/phpMan.php/man/mmap/2/markdown), 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. (See _noatime_, _nodiratime_, and _relatime_ in [**mount**(8)](https://www.chedong.com/phpMan.php/man/mount/8/markdown), and related information in [**mount**(2)](https://www.chedong.com/phpMan.php/man/mount/2/markdown).) In addition, the atime timestamp is not updated if a file is opened with the **O**___**NOATIME** flag; see [**open**(2)](https://www.chedong.com/phpMan.php/man/open/2/markdown). File creation (birth) timestamp (btime) (not returned in the _stat_ structure); _statx.stx_btime_ The file's creation timestamp. This is set on file creation and not changed subse‐ quently. 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, by [**mknod**(2)](https://www.chedong.com/phpMan.php/man/mknod/2/markdown), [**truncate**(2)](https://www.chedong.com/phpMan.php/man/truncate/2/markdown), [**utime**(2)](https://www.chedong.com/phpMan.php/man/utime/2/markdown), and [**write**(2)](https://www.chedong.com/phpMan.php/man/write/2/markdown) (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 is _not_ 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 set‐ ting inode information (i.e., owner, group, link count, mode, etc.). The timestamp fields report time measured with a zero point at the _Epoch_, 1970-01-02 00:00:00 +0000, UTC (see [**time**(7)](https://www.chedong.com/phpMan.php/man/time/7/markdown)). 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 the _stat_ and _statx_ structures are defined as structures that include a nanosecond component. See [**stat**(2)](https://www.chedong.com/phpMan.php/man/stat/2/markdown) and [**statx**(2)](https://www.chedong.com/phpMan.php/man/statx/2/markdown) for details. On filesystems that do not support subsecond timestamps, the nanosecond fields in the _stat_ and _statx_ structures are returned with the value 0. ### The file type and mode The _stat.st_mode_ field (for [**statx**(2)](https://www.chedong.com/phpMan.php/man/statx/2/markdown), the _statx.stx_mode_ field) contains the file type and mode. 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_ and 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 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 in _st_mode_ to be written more concisely: ### S___ISREG(m) ### S___ISDIR(m) ### S___ISCHR(m) ### S___ISBLK(m) ### S___ISFIFO(m) ### S___ISLNK(m) ### S___ISSOCK(m) 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 follow‐ ing 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, defini‐ tions 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**___**EX**‐‐ **TENDED**. The definition of **S**___**ISSOCK**() is exposed if any of the following feature test macros is de‐ fined: ___**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**. 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)](https://www.chedong.com/phpMan.php/man/execve/2/markdown)) **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. 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)](https://www.chedong.com/phpMan.php/man/execve/2/markdown). 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. ## CONFORMING TO If you need to obtain the definition of the _blkcnt_t_ or _blksize_t_ types from __, then define ___**XOPEN**___**SOURCE** with the value 500 or greater (before including _any_ header files). POSIX.1-1990 did not describe the **S**___**IFMT**, **S**___**IFSOCK**, **S**___**IFLNK**, **S**___**IFREG**, **S**___**IFBLK**, **S**___**IFDIR**, **S**___**IFCHR**, **S**___**IFIFO**, **S**___**ISVTX** constants, but instead specified the use of the macros **S**___**ISDIR**(), and so on. The **S**___**IF*** constants are present in POSIX.1-2001 and later. The **S**___**ISLNK**() and **S**___**ISSOCK**() macros were not in POSIX.1-1996, but both are present in POSIX.1-2001; the former is from SVID 4, the latter from SUSv2. UNIX V7 (and later systems) had **S**___**IREAD**, **S**___**IWRITE**, **S**___**IEXEC**, where POSIX prescribes the syn‐ onyms **S**___**IRUSR**, **S**___**IWUSR**, **S**___**IXUSR**. ## NOTES 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 in‐ terpreted as a string). ## SEE ALSO [**stat**(1)](https://www.chedong.com/phpMan.php/man/stat/1/markdown), [**stat**(2)](https://www.chedong.com/phpMan.php/man/stat/2/markdown), [**statx**(2)](https://www.chedong.com/phpMan.php/man/statx/2/markdown), [**symlink**(7)](https://www.chedong.com/phpMan.php/man/symlink/7/markdown) ## COLOPHON This page is part of release 5.10 of the Linux _man-pages_ project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at . Linux 2020-08-13 [INODE(7)](https://www.chedong.com/phpMan.php/man/INODE/7/markdown)