{
    "mode": "man",
    "parameter": "inode",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/inode/7/json",
    "generated": "2026-06-03T00:20:22Z",
    "sections": {
        "NAME": {
            "content": "inode - file inode information\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "Each  file has an inode containing metadata about the file.  An application can retrieve this\nmetadata using stat(2) (or related calls), which returns a stat structure, or statx(2), which\nreturns a statx structure.\n\nThe  following  is a list of the information typically found in, or associated with, the file\ninode, with the names of the corresponding structure fields returned by stat(2) and statx(2):\n\nDevice where inode resides\nstat.stdev; statx.stxdevminor and statx.stxdevmajor\n\nEach inode (as well as the associated file) resides in a filesystem that is hosted  on\na device.  That device is identified by the combination of its major ID (which identi‐\nfies the general class of device) and minor ID (which identifies a  specific  instance\nin the general class).\n\nInode number\nstat.stino; statx.stxino\n\nEach  file in a filesystem has a unique inode number.  Inode numbers are guaranteed to\nbe unique only within a filesystem (i.e., the same inode numbers may be used  by  dif‐\nferent  filesystems,  which  is  the  reason  that hard links may not cross filesystem\nboundaries).  This field contains the file's inode number.\n\nFile type and mode\nstat.stmode; statx.stxmode\n\nSee the discussion of file type and mode, below.\n\nLink count\nstat.stnlink; statx.stxnlink\n\nThis field contains the number of hard links to the file.  Additional links to an  ex‐\nisting file are created using link(2).\n\nUser ID\nstuid stat.stuid; statx.stxuid\n\nThis field records the user ID of the owner of the file.  For newly created files, the\nfile user ID is the effective user ID of the creating process.  The user ID of a  file\ncan be changed using chown(2).\n\nGroup ID\nstat.stgid; statx.stxgid\n\nThe inode records the ID of the group owner of the file.  For newly created files, the\nfile group ID is either the group ID of the parent directory or the effective group ID\nof  the  creating  process, depending on whether or not the set-group-ID bit is set on\nthe parent directory (see below).  The group  ID  of  a  file  can  be  changed  using\nchown(2).\n\nDevice represented by this inode\nstat.strdev; statx.stxrdevminor and statx.stxrdevmajor\n\nIf  this  file (inode) represents a device, then the inode records the major and minor\nID of that device.\n\nFile size\nstat.stsize; statx.stxsize\n\nThis field gives the size of the file (if it is a regular file or a symbolic link)  in\nbytes.  The size of a symbolic link is the length of the pathname it contains, without\na terminating null byte.\n\nPreferred block size for I/O\nstat.stblksize; statx.stxblksize\n\nThis field gives the \"preferred\" blocksize for efficient filesystem I/O.  (Writing  to\na file in smaller chunks may cause an inefficient read-modify-rewrite.)\n\nNumber of blocks allocated to the file\nstat.stblocks; statx.stxsize\n\nThis field indicates the number of blocks allocated to the file, 512-byte units, (This\nmay be smaller than stsize/512 when the file has holes.)\n\nThe POSIX.1 standard notes that the unit for the stblocks member of the  stat  struc‐\nture  is  not defined by the standard.  On many  implementations it is 512 bytes; on a\nfew systems, a different unit is used, such as 1024.  Furthermore, the unit may differ\non a per-filesystem basis.\n\nLast access timestamp (atime)\nstat.statime; statx.stxatime\n\nThis  is  the file's last access timestamp.  It is changed by file accesses, for exam‐\nple, by execve(2), mknod(2), pipe(2), utime(2), and read(2) (of more than zero bytes).\nOther interfaces, such as mmap(2), may or may not update the atime timestamp\n\nSome filesystem types allow mounting in such a way that file and/or directory accesses\ndo not cause an update of the atime timestamp.  (See noatime, nodiratime, and relatime\nin  mount(8),  and related information in mount(2).)  In addition, the atime timestamp\nis not updated if a file is opened with the ONOATIME flag; see open(2).\n\nFile creation (birth) timestamp (btime)\n(not returned in the stat structure); statx.stxbtime\n\nThe file's creation timestamp.  This is set on file creation and  not  changed  subse‐\nquently.\n\nThe  btime timestamp was not historically present on UNIX systems and is not currently\nsupported by most Linux filesystems.\n\nLast modification timestamp (mtime)\nstat.stmtime; statx.stxmtime\n\nThis is the file's last modification timestamp.  It is changed by file  modifications,\nfor  example,  by  mknod(2),  truncate(2),  utime(2),  and write(2) (of more than zero\nbytes).  Moreover, the mtime timestamp of a directory is changed by  the  creation  or\ndeletion  of  files in that directory.  The mtime timestamp is not changed for changes\nin owner, group, hard link count, or mode.\n\nLast status change timestamp (ctime)\nstat.stctime; statx.stxctime\n\nThis is the file's last status change timestamp.  It is changed by writing or by  set‐\nting inode information (i.e., owner, group, link count, mode, etc.).\n\nThe timestamp fields report time measured with a zero point at the Epoch, 1970-01-02 00:00:00\n+0000, UTC (see time(7)).\n\nNanosecond timestamps are supported on XFS,  JFS,  Btrfs,  and  ext4  (since  Linux  2.6.23).\nNanosecond  timestamps  are  not  supported  in ext2, ext3, and Reiserfs.  In order to return\ntimestamps with nanosecond precision, the timestamp fields in the stat and  statx  structures\nare  defined as structures that include a nanosecond component.  See stat(2) and statx(2) for\ndetails.  On filesystems that do not support subsecond timestamps, the nanosecond  fields  in\nthe stat and statx structures are returned with the value 0.\n",
            "subsections": [
                {
                    "name": "The file type and mode",
                    "content": "The  stat.stmode  field  (for statx(2), the statx.stxmode field) contains the file type and\nmode.\n\nPOSIX refers to the stat.stmode bits corresponding to the mask SIFMT  (see  below)  as  the\nfile  type,  the  12 bits corresponding to the mask 07777 as the file mode bits and the least\nsignificant 9 bits (0777) as the file permission bits.\n\nThe following mask values are defined for the file type:\n\nSIFMT     0170000   bit mask for the file type bit field\n\nSIFSOCK   0140000   socket\nSIFLNK    0120000   symbolic link\nSIFREG    0100000   regular file\nSIFBLK    0060000   block device\nSIFDIR    0040000   directory\nSIFCHR    0020000   character device\nSIFIFO    0010000   FIFO\n\nThus, to test for a regular file (for example), one could write:\n\nstat(pathname, &sb);\nif ((sb.stmode & SIFMT) == SIFREG) {\n/* Handle regular file */\n}\n\nBecause tests of the above form are common, additional macros are defined by POSIX  to  allow\nthe test of the file type in stmode to be written more concisely:\n"
                },
                {
                    "name": "S___ISREG(m)",
                    "content": ""
                },
                {
                    "name": "S___ISDIR(m)",
                    "content": ""
                },
                {
                    "name": "S___ISCHR(m)",
                    "content": ""
                },
                {
                    "name": "S___ISBLK(m)",
                    "content": ""
                },
                {
                    "name": "S___ISFIFO(m)",
                    "content": ""
                },
                {
                    "name": "S___ISLNK(m)",
                    "content": ""
                },
                {
                    "name": "S___ISSOCK(m)",
                    "content": "The preceding code snippet could thus be rewritten as:\n\nstat(pathname, &sb);\nif (SISREG(sb.stmode)) {\n/* Handle regular file */\n}\n\nThe definitions of most of the above file type test macros are provided if any of the follow‐\ning feature test macros is defined: BSDSOURCE (in glibc 2.19 and earlier), SVIDSOURCE (in\nglibc  2.19 and earlier), or DEFAULTSOURCE (in glibc 2.20 and later).  In addition, defini‐\ntions of all of the above macros except SIFSOCK and SISSOCK() are provided if XOPENSOURCE\nis defined.\n\nThe  definition of SIFSOCK can also be exposed either by defining XOPENSOURCE with a value\nof 500 or greater or (since glibc 2.24) by defining both XOPENSOURCE and  XOPENSOURCEEX‐‐\nTENDED.\n\nThe  definition  of  SISSOCK() is exposed if any of the following feature test macros is de‐\nfined: BSDSOURCE (in glibc 2.19 and earlier), DEFAULTSOURCE (in glibc  2.20  and  later),\nXOPENSOURCE  with  a  value  of  500 or greater, POSIXCSOURCE with a value of 200112L or\ngreater, or (since glibc 2.24) by defining both XOPENSOURCE and XOPENSOURCEEXTENDED.\n\nThe following mask values are defined for the file mode component of the stmode field:\n\nSISUID     04000   set-user-ID bit (see execve(2))\nSISGID     02000   set-group-ID bit (see below)\nSISVTX     01000   sticky bit (see below)\n\nSIRWXU     00700   owner has read, write, and execute permission\nSIRUSR     00400   owner has read permission\nSIWUSR     00200   owner has write permission\nSIXUSR     00100   owner has execute permission\n\nSIRWXG     00070   group has read, write, and execute permission\nSIRGRP     00040   group has read permission\nSIWGRP     00020   group has write permission\nSIXGRP     00010   group has execute permission\n\nSIRWXO     00007   others (not in group) have read,  write,  and\nexecute permission\nSIROTH     00004   others have read permission\nSIWOTH     00002   others have write permission\nSIXOTH     00001   others have execute permission\n\nThe  set-group-ID bit (SISGID) has several special uses.  For a directory, it indicates that\nBSD semantics are to be used for that directory: files created there inherit their  group  ID\nfrom  the directory, not from the effective group ID of the creating process, and directories\ncreated there will also get the SISGID bit set.  For an executable  file,  the  set-group-ID\nbit  causes the effective group ID of a process that executes the file to change as described\nin execve(2).  For a file that does not have the group execution bit (SIXGRP) set, the  set-\ngroup-ID bit indicates mandatory file/record locking.\n\nThe sticky bit (SISVTX) on a directory means that a file in that directory can be renamed or\ndeleted only by the owner of the file, by the owner of the directory,  and  by  a  privileged\nprocess.\n"
                }
            ]
        },
        "CONFORMING TO": {
            "content": "If  you  need  to obtain the definition of the blkcntt or blksizet types from <sys/stat.h>,\nthen define XOPENSOURCE with the value 500 or greater (before including any header files).\n\nPOSIX.1-1990 did not describe the  SIFMT,  SIFSOCK,  SIFLNK,  SIFREG,  SIFBLK,  SIFDIR,\nSIFCHR,  SIFIFO,  SISVTX constants, but instead specified the use of the macros SISDIR(),\nand so on.  The SIF* constants are present in POSIX.1-2001 and later.\n\nThe SISLNK() and SISSOCK() macros were  not  in  POSIX.1-1996,  but  both  are  present  in\nPOSIX.1-2001; the former is from SVID 4, the latter from SUSv2.\n\nUNIX V7  (and  later systems) had SIREAD, SIWRITE, SIEXEC, where POSIX prescribes the syn‐\nonyms SIRUSR, SIWUSR, SIXUSR.\n",
            "subsections": []
        },
        "NOTES": {
            "content": "For  pseudofiles  that  are  autogenerated  by  the  kernel,  the  file  size  (stat.stsize;\nstatx.stxsize) reported by the kernel is not accurate.  For example, the value 0 is returned\nfor many files under the /proc directory, while various files under /sys  report  a  size  of\n4096  bytes,  even though the file content is smaller.  For such files, one should simply try\nto read as many bytes as possible (and append '\\0' to the returned buffer if it is to be  in‐\nterpreted as a string).\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "stat(1), stat(2), statx(2), symlink(7)\n",
            "subsections": []
        },
        "COLOPHON": {
            "content": "This  page  is  part  of  release  5.10 of the Linux man-pages project.  A description of the\nproject, information about reporting bugs, and the latest version of this page, can be  found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux                                        2020-08-13                                     INODE(7)",
            "subsections": []
        }
    },
    "summary": "inode - file inode information",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "stat",
            "section": "1",
            "url": "https://www.chedong.com/phpMan.php/man/stat/1/json"
        },
        {
            "name": "stat",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/stat/2/json"
        },
        {
            "name": "statx",
            "section": "2",
            "url": "https://www.chedong.com/phpMan.php/man/statx/2/json"
        },
        {
            "name": "symlink",
            "section": "7",
            "url": "https://www.chedong.com/phpMan.php/man/symlink/7/json"
        }
    ]
}