inode(7) Miscellaneous Information Manual inode(7)

ИМЯ

inode - описание файловой иноды

ОПИСАНИЕ

Для каждого файла существует инода (inode), содержащая метаданные файла. Приложение может получить эти метаданные с помощью stat(2) (и подобных вызовов), который возвращает структуру stat, и statx(2), который возвращает структуру statx.

В следующем списке показана информация, которую, обычно, можно найти или которая относится к файловой иноде в полях соответствующей структуры, возвращаемой stat(2) и statx(2):

Устройство, на котором находится инода
stat.st_dev; statx.stx_dev_minor и statx.stx_dev_major
Каждая инода (а также связанный с ней файл) располагается в файловой системе, которая находится на устройстве. Это устройство опознаётся по комбинации своих основного (определяет общий класс устройства) и вспомогательного (определяет конкретный экземпляр в общем классе) идентификаторов.
Номер иноды
stat.st_ino; statx.stx_ino
Каждый файл в файловой системе имеет уникальный номер иноды. Для номеров инод гарантируется уникальность только внутри файловой системы (т. е., одинаковые номера инод могут использоваться в разных файловых системах, из-за чего жёсткие ссылки не могут пересекать границы файловой системы). В этом поле содержится номер иноды файла.
Тип файла и режим
stat.st_mode; statx.stx_mode
Описание типа файла и режим приведены ниже.
Счётчик ссылок
stat.st_nlink; statx.stx_nlink
Это поле содержит количество жёстких ссылок на файл. Дополнительные ссылки на существующий файл созданы с помощью link(2).
Пользовательский идентификатор
stat.st_uid; statx.stx_uid
В этом поле содержится идентификатор пользователя, которому принадлежит файл. При создании файла идентификатору пользователя файла присваивается идентификатор эффективного пользователя создающего процесса. Идентификатор пользователя файла можно изменить с помощью chown(2).
Идентификатор группы
stat.st_gid; statx.stx_gid
В этом поле содержится идентификатор группы, которой принадлежит файл. При создании файла идентификатору группы файла присваивается идентификатор группы родительского каталога или идентификатор эффективной группы создающего процесса, в зависимости от наличия бита set-group-ID на родительском каталоге (смотрите ниже). Идентификатор группы файла можно изменить с помощью chown(2).
Устройство, представляемое этой инодой
stat.st_rdev; statx.stx_rdev_minor и statx.stx_rdev_major
Если этот файл (инода) представляет устройство, то инода хранит основной и вспомогательный идентификатор этого устройства.
Размер файла
stat.st_size; statx.stx_size
Размер файла (если он обычный или является символьной ссылкой) в байтах. Размер символьной ссылки равен длине пути файла, на который она ссылается, без конечного нулевого байта.
Предпочтительный размер блока для ввода/вывода
stat.st_blksize; statx.stx_blksize
«Предпочтительный» размер блока для эффективного ввода/вывода в файловой системе (запись в файл более мелкими порциями может привести к неэффективному чтению/изменению/повторной записи).
Количество блоков, выделенных файлу
stat.st_blocks; statx.stx_blocks
Количество блоков (по 512 байт), выделенных для файла (может быть меньше, чем st_size/512, когда в файле есть пропуски (holes)).
В стандарте POSIX.1 отмечено, что размер единиц значения st_blocks структуры stat стандартом не определяется. Во многих реализациях он равен 512 байт; в некоторых системах используются другой — 1024. Кроме этого, размер единиц может отличаться для разных файловых систем.
Метка времени последнего доступа (atime)
stat.st_atime; statx.stx_atime
Метка времени последнего доступ к файлу. Изменяется при доступе к файлу, например, при выполнении execve(2), mknod(2), pipe(2), utime(2) и read(2) (при чтении ненулевого количества байт). Другие интерфейсы, например mmap(2), могут изменять метку, но могут и не делать этого.
Некоторые типы файловых систем позволяют выполнить монтирование таким образом, что факт доступа к файлу или каталогу не вызовет изменение метки atime (смотрите описание noatime, nodiratime и relatime в mount(8) и связанную с ними информацию в mount(2)). Также, поле метка atime не обновляется, если файл открыт с флагом O_NOATIME; смотрите open(2).
Метка времени создания файла (btime)
(не возвращается в структуре stat); statx.stx_btime
Метка времени создания файла. Устанавливается при создании файла и после этого не изменяется.
Метка btime отсутствовала в системах UNIX и в настоящее время не поддерживается в большинстве файловых систем Linux.
Метка времени последнего изменения (mtime)
stat.st_mtime; statx.stx_mtime
Метка времени последнего изменения файла. Изменяется при изменении файла, например, при выполнении mknod(2), truncate(2), utime(2) и write(2) (если записано не менее одного байта). Кроме того, у каталога метка mtime изменяется при создании и удалении файлов в этом каталоге. Метка mtime не изменяется при изменении владельца, группы, количества жёстких ссылок или режима доступа.
Метка времени последнего изменения состояния (ctime)
stat.st_ctime; statx.stx_ctime
Метка времени последнего изменения состояния файла. Изменяется при записи или установке информации иноды (т. е., владельце, группе, количестве ссылок, режиме и т. д.).

The timestamp fields report time measured with a zero point at the Epoch, 1970-01-01 00:00:00 +0000, UTC (see time(7)).

Метки времени наносекундной точности поддерживаются в XFS, JFS, Btrfs и ext4 (начиная с Linux 2.6.23). Метки времени наносекундной точности не поддерживаются в ext2, ext3 и Reiserfs. Для возвращать метки времени наносекундной точности поля меток времени в структурах stat и statx определены как структуры, включающие наносекундную составляющую. Подробности приведены в stat(2) и statx(2). Для файловых систем, не поддерживающих субсекундные метки времени, наносекундные поля в возвращаемых структурах stat и statx имеют значение 0.

Тип файла и режим

Поле stat.st_modestatx(2) — поле statx.stx_mode ) содержит тип файл и режим.

В POSIX относятся к битам stat.st_mode равным маске S_IFMT (смотрите ниже) как к типу файла (file type), 12 битам, соответствующим маске 07777, как к битам режима файла (file mode bits) и наименее значащим 9 битам (0777) как к битам доступа к файлу (file permission bits).

Следующие значения масок определены для типа файла:

S_IFMT 0170000 битовая маска битового поля для типа файла
S_IFSOCK 0140000 socket
S_IFLNK 0120000 символьная ссылка
S_IFREG 0100000 обычный файл
S_IFBLK 0060000 блочное устройство
S_IFDIR 0040000 каталог
S_IFCHR 0020000 символьное устройство
S_IFIFO 0010000 FIFO

Таким образом, чтобы проверить обычный файл (например) на возможность записи:


stat(pathname, &sb);
if ((sb.st_mode & S_IFMT) == S_IFREG) {
    /* обработка обычного файла */
}

Так как приведённое выше тестирование имеет общий вид, в POSIX определены дополнительные макросы, которые позволяют тестировать тип файла в st_mode более краткой записью:

обычный файл?
каталог?
символьное устройство?
блочное устройство?
FIFO (именованный канал)?
символьная ссылка? (нет в POSIX.1-1996.)
сокет? (нет в POSIX.1-1996.)

The preceding code snippet could thus be rewritten as:


stat(pathname, &sb);
if (S_ISREG(sb.st_mode)) {
    /* обработка обычного файла */
}

Определений большинства показанных ранее макросов тестирования типа файла доступно, если определён любой из следующих макросов тестирования свойств: _BSD_SOURCE (в glibc 2.19 и старее), _SVID_SOURCE (в glibc 2.19 и старее) или _DEFAULT_SOURCE (в glibc 2.20 и новее). Также, определение всех макросов, за исключением S_IFSOCK и S_ISSOCK(), доступны при наличии _XOPEN_SOURCE.

Определение S_IFSOCK также можно получить определив _XOPEN_SOURCE со значением 500 или более или (начиная с glibc 2.24) определением _XOPEN_SOURCE и _XOPEN_SOURCE_EXTENDED одновременно.

Определение S_ISSOCK() доступно, если определён любой из следующих макросов тестирования свойств: _BSD_SOURCE (в glibc 2.19 и старее), _DEFAULT_SOURCE (в glibc 2.20 и новее), _XOPEN_SOURCE со значением 500 или более или _POSIX_C_SOURCE со значением 200112L или более или (начиная с glibc 2.24) _XOPEN_SOURCE и _XOPEN_SOURCE_EXTENDED одновременно.

Следующие значения масок определены для компонента режима доступа к файлу в поле st_mode:

S_ISUID 04000 бит set-user-ID (смотрите execve(2))
S_ISGID 02000 бит set-group-ID (смотрите далее)
S_ISVTX 01000 закрепляющий бит (смотрите далее)
S_IRWXU 00700 владелец имеет права на чтение, запись и выполнение
S_IRUSR 00400 владелец имеет право на чтение
S_IWUSR 00200 владелец имеет право на запись
S_IXUSR 00100 владелец имеет право на выполнение
S_IRWXG 00070 группа имеет права на чтение, запись и выполнение
S_IRGRP 00040 имеет право на чтение
S_IWGRP 00020 группа имеет право на запись
S_IXGRP 00010 группа имеет право на выполнение
S_IRWXO 00007 все остальные (вне группы) имеют права на чтение, запись и выполнение
S_IROTH 00004 все остальные имеют право на чтение
S_IWOTH 00002 все остальные имеют право на запись
S_IXOTH 00001 все остальные имеют право на выполнение

Бит set-group-ID (S_ISGID) имеет несколько специальных применений. Для каталога он указывает, что используется семантика BSD: файлы, создаваемые в каталоге, наследуют ID группы этого каталога, а не фактический ID группы создающего процесса, а для подкаталогов данного каталога также будет установлен бит S_ISGID. Для исполняемого файла бит set-group-ID заставляет изменить фактический ID группы процесса, который выполняет файл, согласно правилам, описанным в execve(2). Если файл не имеет бита выполнения группой (S_IXGRP), то бит set-group-ID означает обязательную (mandatory) блокировку файла/записей.

Закрепляющий (sticky) бит (S_ISVTX) на каталоге означает, что файлы в этом каталоге могут быть удалены или переименованы только владельцем файла, владельцем каталога и привилегированным процессом.

СТАНДАРТЫ

POSIX.1-2008.

ИСТОРИЯ

POSIX.1-2001.

POSIX.1-1990 did not describe the S_IFMT, S_IFSOCK, S_IFLNK, S_IFREG, S_IFBLK, S_IFDIR, S_IFCHR, S_IFIFO, and S_ISVTX constants, but instead specified the use of the macros S_ISDIR() and so on.

The S_ISLNK() and S_ISSOCK() macros were not in POSIX.1-1996; the former is from SVID 4, the latter from SUSv2.

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.

ПРИМЕЧАНИЯ

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)

ПЕРЕВОД

Русский перевод этой страницы руководства разработал Azamat Hackimov <azamat.hackimov@gmail.com>, Dmitriy S. Seregin <dseregin@59.ru>, Yuri Kozlov <yuray@komyakino.ru> и Иван Павлов <pavia00@gmail.com>

Этот перевод является свободной программной документацией; он распространяется на условиях общедоступной лицензии GNU (GNU General Public License - GPL, https://www.gnu.org/licenses/gpl-3.0.html версии 3 или более поздней) в отношении авторского права, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ.

Если вы обнаружите какие-либо ошибки в переводе этой страницы руководства, пожалуйста, сообщите об этом разработчику по его адресу электронной почты или по адресу списка рассылки русских переводчиков.

2 мая 2024 г. Linux man-pages 6.8