Provided by: manpages-ru-dev_4.21.0-2_all 
ИМЯ
open, openat, creat - открывает и, возможно, создаёт файл
LIBRARY
Standard C library (libc, -lc)
СИНТАКСИС
#include <fcntl.h>
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
int creat(const char *pathname, mode_t mode);
int openat(int dirfd, const char *pathname, int flags);
int openat(int dirfd, const char *pathname, int flags, mode_t mode);
/* Documented separately, in openat2(2): */
int openat2(int dirfd, const char *pathname,
const struct open_how *how, size_t size);
Требования макроса тестирования свойств для glibc (см. feature_test_macros(7)):
openat():
Начиная с glibc 2.10:
_POSIX_C_SOURCE >= 200809L
До glibc 2.10:
_ATFILE_SOURCE
ОПИСАНИЕ
Системный вызов open() открывает файл, на который указывает pathname. Если заданный файл
не существует, то он может быть создан open() (если в flags задан O_CREAT).
The return value of open() is a file descriptor, a small, nonnegative integer that is an
index to an entry in the process's table of open file descriptors. The file descriptor is
used in subsequent system calls (read(2), write(2), lseek(2), fcntl(2), etc.) to refer to
the open file. The file descriptor returned by a successful call will be the
lowest-numbered file descriptor not currently open for the process.
По умолчанию, новый файловый дескриптор остаётся открытым при вызове execve(2) (т. е.,
флаг FD_CLOEXEC файлового дескриптора, описанный в fcntl(2), изначально сброшен; для
изменения поведения по умолчанию можно использовать флаг O_CLOEXEC, он описан далее).
Файловое смещение устанавливается на начало файла (см. lseek(2)).
Вызов open() создаёт новое открытое файловое описание — запись в системной таблице
открытых файлов. В этой записи хранится смещение и флаги состояния файла (смотрите ниже).
Файловый дескриптор — это ссылка на открытое файловое описание; с этой ссылкой ничего не
происходит при последующем удалении pathname или переуказании имени на другой файл.
Дополнительную информацию об открытых файловых описаниях смотрите в разделе ЗАМЕЧАНИЯ.
Параметр flags должен содержать один из следующих режимов доступа: O_RDONLY (только для
чтения), O_WRONLY (только для записи) или O_RDWR (для чтения и записи).
Также в flags можно указывать флаги создания и состояния файла, объединяя их битовой
операцией ИЛИ. Флаги создания файла: O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY,
O_NOFOLLOW, O_TMPFILE и O_TRUNC. Флаги состояния файла — все оставшиеся, перечислены ниже.
Различие между двумя этими группами в том, что флаги создания влияют на работу самой
операции открытия, а флаги состояния влияют на работу последующих операций ввода-вывода.
Флаги состояния можно запросить и (в некоторых случаях) изменить; смотрите fcntl(2).
Полный список флагов создания и флагов состояния файла:
O_APPEND
Файл открывается в режиме добавления. Перед каждым вызовом write(2), файловое
смещение устанавливается в конец файла, как если бы это делалось с помощью
lseek(2). Изменение файлового смещения и операция записи выполняются атомарно, за
один шаг.
Указание флага O_APPEND может приводить к повреждению файлов в файловых системах
NFS, если одновременно добавляют данные в файл несколько процессов. Это происходит
из-за того, что NFS не поддерживает добавление в файл, поэтому клиентское ядро
имитирует такое поведение, но при этом нельзя избежать состязательности процессов.
O_ASYNC
Включает ввод-вывод, управляемый сигналом: генерирует сигнал (по умолчанию SIGIO,
но можно изменить с помощью fcntl(2)), когда становится возможным ввод или вывод
для этого файлового дескриптора. Эта возможность доступна только для терминалов,
псевдотерминалов, сокетов, каналов (начиная с Linux 2.6) и FIFO. Подробней смотрите
fcntl(2). Также смотрите ДЕФЕКТЫ далее.
O_CLOEXEC (начиная с Linux 2.6.23)
Устанавливает флаг close-on-exec на новом файловом дескрипторе. Указание данного
флага позволяет программе избежать дополнительной операции fcntl(2) F_SETFD для
установки флага FD_CLOEXEC.
Заметим, что использование этого флага обязательно для некоторых многонитиевых
программ, так как использование отдельной операции fcntl(2) F_SETFD для установки
флага FD_CLOEXEC недостаточно для избежания состязательности, когда одна нить
открывает файловый дескриптор, а в тоже время другая нить может выполнять fork(2) и
execve(2). В зависимости от порядка выполнения, состязательность может привести к
тому, что файловый дескриптор, возвращённый open(), будет ненамеренно передан
программе, выполняющейся в созданном с помощью fork(2) потомке (такого рода
состязательность, в принципе, возможна для любых системных вызовов, создающих
файловый дескриптор, у которого должен быть установлен флаг close-on-exec, и
различные другие системные вызовы Linux предоставляют эквивалент флагу O_CLOEXEC,
чтобы избежать этой проблемы).
O_CREAT
Если pathname не существует, то создать обычный файл.
Владельцем (ID пользователя) нового файла назначается эффективный идентификатор
пользователя процесса.
Группой владельцев (ID группы) нового файла назначается эффективный идентификатор
группы процесса (согласно System V) или ID группы родительского каталога (согласно
BSD). В Linux это зависит от наличия бита режима set-group-ID на родительском
каталоге: если этот бит установлен, то используется правило BSD; в противном случае
применяется правило System V. В некоторых файловых системах поведение также зависит
от параметров монтирования bsdgroups и sysvgroups, описанных в mount(8).
The mode argument specifies the file mode bits to be applied when a new file is
created. If neither O_CREAT nor O_TMPFILE is specified in flags, then mode is
ignored (and can thus be specified as 0, or simply omitted). The mode argument
must be supplied if O_CREAT or O_TMPFILE is specified in flags; if it is not
supplied, some arbitrary bytes from the stack will be applied as the file mode.
The effective mode is modified by the process's umask in the usual way: in the
absence of a default ACL, the mode of the created file is (mode & ~umask).
Note that mode applies only to future accesses of the newly created file; the
open() call that creates a read-only file may well return a read/write file
descriptor.
Символьные константы, используемые в mode:
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 все остальные имеют права на выполнение файла
Согласно POSIX, в случае, если в mode указаны другие биты, их воздействие не
определено. В Linux для mode также доступны следующие биты:
S_ISUID 0004000 бит set-user-ID
S_ISGID 0002000 бит set-group-ID (смотрите inode(7)).
S_ISVTX 0001000 закрепляющий бит bit (смотрите inode(7)).
O_DIRECT (начиная с Linux 2.4.10)
Попытаться минимизировать влияние кэширования ввода-вывода при чтении и записи в
файл. Обычно, это ухудшает производительность, но полезно для особых случаев,
например, когда приложение выполняет кэширование самостоятельно. Файловый
ввод-вывод выполняется непосредственно в/из буферов пространства пользователя. При
флаге O_DIRECT предпринимаются все усилия для синхронной передачи данных, но это не
гарантирует, как с флагом O_SYNC, передачу данных и необходимых метаданных. Чтобы
гарантировать синхронный ввод-вывод вместе с O_DIRECT нужно использовать O_SYNC.
Дальнейшее описание смотрите далее в разделе ЗАМЕЧАНИЯ.
Семантически похожий интерфейс (но устаревший) для блочных устройств описан в
raw(8).
O_DIRECTORY
If pathname is not a directory, cause the open to fail. This flag was added in
Linux 2.1.126, to avoid denial-of-service problems if opendir(3) is called on a
FIFO or tape device.
O_DSYNC
Операции записи файла будут выполнены согласно требованиям целостности
синхронизации ввода-вывода data.
К времени возврата из write(2) (и подобных) выходные данные уже переданы в
задействованное аппаратное обеспечение вместе со всеми метаданными файла, которые
бы потребовались для получения данных (т. е., как если бы за каждым write(2) был
выполнен вызов fdatasync(2)). Смотрите ЗАМЕЧАНИЯ далее.
O_EXCL Гарантирует, что вызов создаст файл: если этот флаг указан вместе с O_CREAT и
pathname уже существует, то open() завершается ошибкой EEXIST().
При использовании обоих флагов символьные ссылки не поддерживаются: если pathname
является символьной ссылкой, то open() завершается с ошибкой независимо от того,
куда указывает ссылка.
Вообще говоря, поведение с O_EXCL не определено, если этот флаг используется без
O_CREAT. Есть одно исключение: в Linux 2.6 и более новых O_EXCL можно использовать
без O_CREAT, если pathname указывает на блочное устройство. Если блочное устройство
используется в системе (например, смонтировано), то open() завершится с ошибкой
EBUSY.
Флаг O_EXCL поддерживается для NFS только, если используется NFSv3 или новее с
ядром 2.6 или новее. В средах, где в NFS нет поддержки O_EXCL, программы, которые
полагаются на это для выполнения задач блокировок, будут создавать состязательность
процессов. Переносимым программам, которым нужно произвести атомарную блокировку
файла с помощь файла блокировки, необходимо избегать зависимости от поддержки в NFS
флага O_EXCL. В качестве решения можно создать уникальный файл в той же файловой
системе (например, добавив имя узла и PID в название), чтобы создать ссылку на файл
блокировки с помощью link(2). Если link(2) возвращает 0, то блокировка выполнена. В
противном случае используйте stat(2), чтобы убедиться, что количество ссылок на
уникальный файл возросло до двух. Это также означает, что блокировка была успешной.
O_LARGEFILE
(LFS) Позволяет открывать файлы, чей размер нельзя представить типом off_t (но
можно представить типом off64_t). Для получения этого определения должен быть
указан макрос _LARGEFILE64_SOURCE (до включения какого-либо заголовочного файла).
Установка макроса тестирования возможностей _FILE_OFFSET_BITS в значение 64 (вместо
использования O_LARGEFILE) является предпочтительным методом доступа к большим
файлам на 32-битных системах (см. feature_test_macros(7)).
O_NOATIME (начиная с Linux 2.6.8)
Не обновлять время последнего доступа к файлу (st_atime в иноде) при вызове read(2)
для файла.
Этот флаг может использоваться только, если удовлетворяется одно из следующих
условий:
• Эффективный пользовательский идентификатор процесса совпадает идентификатором
владельца файла.
• Вызывающий процесс имеет мандат CAP_FOWNER в своём пользовательском пространстве
имён и UID владельца файла отображён в пространстве имён.
Этот флаг предназначен для использования в программах индексирования и резервного
копирования; он позволяет значительно сократить количество обращений к диску. Флаг
может быть не эффективен на некоторых файловых системах. Например, на NFS, где
запись времени доступа выполняется сервером.
O_NOCTTY
If pathname refers to a terminal device—see tty(4)—it will not become the process's
controlling terminal even if the process does not have one.
O_NOFOLLOW
If the trailing component (i.e., basename) of pathname is a symbolic link, then the
open fails, with the error ELOOP. Symbolic links in earlier components of the
pathname will still be followed. (Note that the ELOOP error that can occur in this
case is indistinguishable from the case where an open fails because there are too
many symbolic links found while resolving components in the prefix part of the
pathname.)
This flag is a FreeBSD extension, which was added in Linux 2.1.126, and has
subsequently been standardized in POSIX.1-2008.
Смотрите также далее O_PATH.
O_NONBLOCK или O_NDELAY
Если возможно, файл открывается в неблокирующем режиме. Ни open(), ни другие
последующие операции ввода-вывода над возвращаемым дескриптором файла не заставят
вызывающий процесс ждать.
Заметим, что установка этого флага не влияет на операции poll(2), select(2),
epoll(7) и подобные, так как их интерфейсы просто информируют вызывающего о том,
что файловый дескриптор «ready», то есть операция ввода-вывода, выполняемая над
файловым дескриптором с флагом O_NONBLOCK, точно не заблокируется.
Обратите внимание, что этот флаг не оказывает влияния на обычные файлы и блочные
устройства, то есть операции ввода-вывода будут блокироваться на короткое время,
если будет запрошено активность устройства, вне зависимости от установки флага
O_NONBLOCK. Семантика O_NONBLOCK может быть когда-нибудь реализована, поэтому
приложения не должны зависеть от блокировок при указании данного флага для обычных
файлов и блочных устройств.
Для работы с каналами FIFO также смотрите fifo(7). Обсуждение влияния O_NONBLOCK в
сочетании с обязательной файловой блокировкой или арендой (lease) смотрите в
fcntl(2).
O_PATH (начиная с Linux 2.6.39)
Получить файловый дескриптор, который можно использовать для двух целей: для
указания положения в дереве файловой системы и для выполнения операций, работающих
исключительно на уровне файловых дескрипторов. Сам файл не открывается и другие
файловые операции (например, read(2), write(2), fchmod(2), fchown(2), fgetxattr(2),
ioctl(2), mmap(2)) завершатся с ошибкой EBADF.
Следующие операции могут выполняться над полученным файловым дескриптором:
• close(2).
• fchdir(2), если файловый дескриптор указывает на каталог (начиная с Linux 3.5).
• fstat(2) (начиная с Linux 3.6).
• fstatfs(2) (начиная с Linux 3.12).
• Создание дубликата файлового дескриптора (dup(2), fcntl(2) F_DUPFD и т.д.).
• Получение и установка флагов файловых дескрипторов (fcntl(2) F_GETFD и
F_SETFD).
• Получение флагов состояния открытого файла с помощью операции fcntl(2) F_GETFL:
в возвращаемые флаги будет включён бит O_PATH.
• Передача файлового дескриптора в аргументе dirfd для openat() и других системных
вызовов «*at()». К ним относится linkat(2) с флагом AT_EMPTY_PATH (или через
procfs с помощью AT_SYMLINK_FOLLOW) даже, если файл не является каталогом.
• Передача файлового дескриптора в другой процесс через доменный сокет UNIX
(смотрите SCM_RIGHTS в unix(7)).
Если в flags указан O_PATH, то биты флагов, отличные от O_CLOEXEC, O_DIRECTORYи
O_NOFOLLOW, игнорируются.
Открытие файла или каталога при указании флага O_PATH не требует прав на сам объект
(но требует права на выполнение каталогов из префикса пути). В зависимости от
последующей операции может выполняться проверка определённых прав на файл
(например, fchdir(2) требует права на выполнение у каталога, указанного в аргументе
файлового дескриптора). Напротив, для получения ссылки на объект файловой системы
при открытии с флагом O_RDONLY от вызывающего требуется право на чтение объекта,
даже если для последующей операции (например, fchdir(2), fstat(2)) не требуется
права чтения объекта.
Если pathname является символьной ссылкой и также указан флаг O_NOFOLLOW, то вызов
возвращает файловый дескриптор, указывающий на символьную ссылку. Этот файловый
дескриптор можно использовать в аргументе dirfd для вызовов fchownat(2),
fstatat(2), linkat(2) и readlinkat(2) с пустым именем пути, чтобы выполнить
операцию над символьной ссылкой.
Если pathname ссылается на автоматическую точку монтирования, которая ещё не
включилась, и поэтому к ней не примонтированы другие файловые системы, то вызов
возвращает файловый дескриптор, указывающий на каталог автомонтирования, не вызывая
запуск монтирования. Затем можно использовать вызов fstatfs(2) для определения,
является ли автоматическая точка монтирования включённой (.f_type ==
AUTOFS_SUPER_MAGIC).
Одним из вариантов использования флага O_PATH для обычных файлов — предоставление
эквивалента функции O_EXEC, описанной POSIX.1. Вызывающий может открыть файл, для
которого имеется право на выполнение, но не права на чтение, и затем выполнить этот
файл следующими действиями:
char buf[PATH_MAX];
fd = open("some_prog", O_PATH);
snprintf(buf, PATH_MAX, "/proc/self/fd/%d", fd);
execl(buf, "some_prog", (char *) NULL);
Файловый дескриптор с O_PATH также может быть передан в качестве аргумента
fexecve(3).
O_SYNC Операции записи файла будут выполнены согласно требованиям целостности
синхронизации ввода-вывода file (по сравнению с целостностью синхронизации
ввода-вывода data, предоставляемой O_DSYNC).
На момент возврата из write(2) (или подобной функции) выходные данные и все
метаданные файла уже переданы в задействованное аппаратное обеспечение (т. е., как
если бы за каждым write(2) был выполнен вызов fsync(2)). Смотрите ЗАМЕЧАНИЯ далее.
O_TMPFILE (начиная с Linux 3.11)
Создание безымянного временного обычного файла. В аргументе pathname указывается
каталог; безымянная inode будет создана в файловой системе этого каталога. Всё
записанное в полученный файл будет потеряно при закрытии последнего файлового
дескриптора, если файлу не будет назначено имя.
Флаг O_TMPFILE должен быть указан вместе с O_RDWR или O_WRONLY и, необязательно,
O_EXCL. Если O_EXCL не указан, то можно использовать linkat(2) для ссылки на
временный файл в файловой системе, сделав его постоянным с помощью кода:
char path[PATH_MAX];
fd = open("/path/to/dir", O_TMPFILE | O_RDWR,
S_IRUSR | S_IWUSR);
/* File I/O on 'fd'... */
linkat(fd, "", AT_FDCWD, "/path/for/file", AT_EMPTY_PATH);
/* If the caller doesn't have the CAP_DAC_READ_SEARCH
capability (needed to use AT_EMPTY_PATH with linkat(2)),
and there is a proc(5) filesystem mounted, then the
linkat(2) call above can be replaced with:
snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
AT_SYMLINK_FOLLOW);
*/
В этом случае аргументом mode у open() определяется режим доступа к файлу как с
O_CREAT.
Указание O_EXCL вместе с O_TMPFILE отключает возможность создания символьной ссылки
в файловой системе указанным ранее способом (заметим, что назначение O_EXCL в этом
случае отличается от обычного O_EXCL).
Есть два основных случая использования O_TMPFILE:
• Дополнительное свойство tmpfile(3): свободное от состязательности создание
временных файлов, которые: автоматически удаляются при закрытии; недоступны по
имени; не подвержены атаке через символьные ссылки; не требуют от вызывающего
подбирать уникальное имя.
• Создание файла, который изначально не видим, и который затем заполняется данными
и позволяет изменять атрибуты в файловой системе (fchown(2), fchmod(2),
fsetxattr(2) и т. д.) до автоматического встраивания в файловую систему в
полностью законченном виде (с помощью linkat(2) как описано ранее).
Для O_TMPFILE требуется поддержка в файловой системе; она есть только в нескольких
файловых системах Linux. В первой реализации поддержка предоставлялась в файловых
системах ext2, ext3, ext4, UDF, Minix и tmpfs. Поддержка других файловых систем
появлялась так: XFS (Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); ubifs
(Linux 4.9).
O_TRUNC
Если файл уже существует и является обычным файлом и режим доступа позволяет писать
в этот файл (т.е. установлен флаг O_RDWR или O_WRONLY), то его длина будет урезана
до нуля. Если файл является FIFO или терминальным устройством, то этот флаг
игнорируется. В других случаях действие флага O_TRUNC не определено.
creat()
Вызов creat() эквивалентен вызову open() с значением flags O_CREAT|O_WRONLY|O_TRUNC.
openat()
Системный вызов openat() работает также как системный вызов open(), за исключением
случаев, описанных здесь.
The dirfd argument is used in conjunction with the pathname argument as follows:
• Если в pathname задан абсолютный путь, то dirfd игнорируется.
• If the pathname given in pathname is relative and dirfd is the special value AT_FDCWD,
then pathname is interpreted relative to the current working directory of the calling
process (like open()).
• If the pathname given in pathname is relative, then it is interpreted relative to the
directory referred to by the file descriptor dirfd (rather than relative to the current
working directory of the calling process, as is done by open() for a relative
pathname). In this case, dirfd must be a directory that was opened for reading
(O_RDONLY) or using the O_PATH flag.
If the pathname given in pathname is relative, and dirfd is not a valid file descriptor,
an error (EBADF) results. (Specifying an invalid file descriptor number in dirfd can be
used as a means to ensure that pathname is absolute.)
openat2(2)
The openat2(2) system call is an extension of openat(), and provides a superset of the
features of openat(). It is documented separately, in openat2(2).
ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ
On success, open(), openat(), and creat() return the new file descriptor (a nonnegative
integer). On error, -1 is returned and errno is set to indicate the error.
ОШИБКИ
Вызовы open(), openat() и creat() могут завершаться со следующими ошибками:
EACCES Запрошенный доступ к файлу не разрешён, или один из каталогов в pathname не
позволяет поиск, файл ещё не существует, или доступ для записи в родительский
каталог не разрешён (см. также path_resolution(7)).
EACCES Where O_CREAT is specified, the protected_fifos or protected_regular sysctl is
enabled, the file already exists and is a FIFO or regular file, the owner of the
file is neither the current user nor the owner of the containing directory, and the
containing directory is both world- or group-writable and sticky. For details, see
the descriptions of /proc/sys/fs/protected_fifos and /proc/sys/fs/protected_regular
in proc(5).
EBADF (openat()) pathname is relative but dirfd is neither AT_FDCWD nor a valid file
descriptor.
EBUSY O_EXCL was specified in flags and pathname refers to a block device that is in use
by the system (e.g., it is mounted).
EDQUOT Если указан флаг O_CREAT, файл не существует и исчерпана пользовательская квота на
дисковые блоки или inode файловой системы.
EEXIST pathname уже существует, то были указаны O_CREAT и O_EXCL.
EFAULT Аргумент pathname указывает за пределы доступного адресного пространства.
EFBIG Смотрите EOVERFLOW.
EINTR При блокирующем ожидании завершения открытия медленного устройства (например, FIFO;
см. fifo(7)), вызов был прерван обработчиком сигнала; смотрите signal(7).
EINVAL Файловая система не поддерживает флаг O_DIRECT. Подробности смотрите в ЗАМЕЧАНИЯ.
EINVAL Некорректное значение flags.
EINVAL В flags указан O_TMPFILE, но не указан O_WRONLY или O_RDWR.
EINVAL В flags указан O_CREAT и последний компонент («основная часть» (basename)) нового
файла pathname некорректен (например, содержит недопустимые в нижележащей файловой
системе символы).
EINVAL The final component ("basename") of pathname is invalid (e.g., it contains
characters not permitted by the underlying filesystem).
EISDIR pathname указывает на каталог и тип доступа подразумевает запись ( то есть
установлен флаг O_WRONLY или O_RDWR).
EISDIR Значение pathname ссылается на существующий каталог, в flags указан O_TMPFILE и
один из O_WRONLY или O_RDWR, но версия ядра не предоставляет свойство O_TMPFILE.
ELOOP Во время определения pathname встретилось слишком много символьных ссылок.
ELOOP Значение pathname является символьной ссылкой и в flags установлен O_NOFOLLOW, но
отсутствует O_PATH.
EMFILE Было достигнуто ограничение по количеству открытых файловых дескрипторов на процесс
(смотрите описание RLIMIT_NOFILE в getrlimit(2)).
ENAMETOOLONG
pathname слишком длинен.
ENFILE Достигнуто максимальное количество открытых файлов в системе.
ENODEV pathname ссылается на специальный файл устройства, но соответствующего устройства
не существует (это ошибка в ядре Linux: должно возвращаться ENXIO).
ENOENT Не задан O_CREAT и файл с указанным именем не существует.
ENOENT Один из каталогов в pathname не существует или является повисшей символьной
ссылкой.
ENOENT Значение pathname ссылается на несуществующий каталог, в flags указан O_TMPFILE и
один из O_WRONLY или O_RDWR, но версия ядра не предоставляет свойство O_TMPFILE.
ENOMEM Типом файла с именем является FIFO, но память для буфера FIFO невозможно выделить,
так как достигнуто жёсткое пользовательское ограничение на выделение памяти для
каналов и вызывающий не имеет дополнительных прав; смотрите pipe(7).
ENOMEM Недостаточное количество памяти ядра.
ENOSPC Файл pathname должен быть создан, но на устройстве его содержащем нет места для
нового файла.
ENOTDIR
Компонент, который обозначен как каталог в pathname, таковым не является, или был
указан флаг O_DIRECTORY, но pathname не является каталогом.
ENOTDIR
(openat()) Значение pathname содержит относительный путь и dirfd содержит файловый
дескриптор, указывающий на файл, а не на каталог.
ENXIO Установлены O_NONBLOCK | O_WRONLY , именованный файл имеет тип FIFO и ни один
процесс не открыл FIFO на чтение.
ENXIO Файл является специальным файлом устройства, но соответствующее устройство не
существует.
ENXIO Файл является доменным сокетом UNIX.
EOPNOTSUPP
Файловая система, содержащая pathname, не поддерживает O_TMPFILE.
EOVERFLOW
pathname refers to a regular file that is too large to be opened. The usual
scenario here is that an application compiled on a 32-bit platform without
-D_FILE_OFFSET_BITS=64 tried to open a file whose size exceeds (1<<31)-1 bytes; see
also O_LARGEFILE above. This is the error specified by POSIX.1; before Linux
2.6.24, Linux gave the error EFBIG for this case.
EPERM Задан флаг O_NOATIME, но эффективный ID пользователя вызывающего процесса не
совпадает с владельцем файла и вызывающий не имеет прав.
EPERM Выполнение операции предотвращено опечатыванием (file seal); смотрите fcntl(2).
EROFS pathname указывает на файл на файловой системе, доступной только на чтение, но
запрашивается доступ на запись.
ETXTBSY
pathname указывает на исполняемый файл, который запущен в данный момент, но
запрашивается доступ на запись.
ETXTBSY
pathname указывает на файл, который в данный момент используется как файл подкачки
и был указан флаг O_TRUNC.
ETXTBSY
pathname указывает на файл, который в данный момент читается ядром (например, для
загрузки модуля/микропрограммы) и запрашивается доступ на запись.
EWOULDBLOCK
Указан флаг O_NONBLOCK, но несовместимая аренда (lease) удерживает файл (смотрите
fcntl(2)).
ВЕРСИИ
openat() was added in Linux 2.6.16; library support was added in glibc 2.4.
СТАНДАРТЫ
open(), creat() SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
openat(): POSIX.1-2008.
openat2(2) is Linux-specific.
Флаги O_DIRECT, O_NOATIME, O_PATH и O_TMPFILE есть только в Linux. Для их определения
может потребоваться задать _GNU_SOURCE.
Флаги O_CLOEXEC, O_DIRECTORY и O_NOFOLLOW не указаны в POSIX.1-2001, но есть в
POSIX.1-2008. Начиная с glibc 2.12, их определения можно получить определив или
_POSIX_C_SOURCE со значением большим и равным 200809L, или _XOPEN_SOURCE со значением
большим и равным 700. В glibc 2.11 и старее их определения можно получить определив
_GNU_SOURCE.
Как было отмечено в feature_test_macros(7), такие макросы тестирования свойств как
_POSIX_C_SOURCE, _XOPEN_SOURCE и _GNU_SOURCE, должны быть определены до включения любых
заголовочных файлов.
ЗАМЕЧАНИЯ
В Linux флаг O_NONBLOCK иногда используется в случаях, когда файл только открыть, и не
обязательно будет производиться чтение или запись. Например, он может использоваться для
открытия устройства, чтобы получить его файловый дескриптор для использования в ioctl(2).
Результат работы комбинации флагов O_RDONLY | O_TRUNC в разных реализациях разный (нигде
не определён). Во многих системах файл усекается.
Заметим, что open() может открывать специальные файлы устройств, но creat() не может их
создавать; вместо этого используйте mknod(2).
Если файл только что был создан, его поля st_atime, st_ctime, st_mtime (время последнего
доступа, последней смены состояния и последнего изменения, соответственно; см. stat(2))
устанавливаются в значение текущего времени, и оно совпадает с полями st_ctime и st_mtime
родительского каталога. Или же, если файл изменяется из-за установленного флага O_TRUNC,
то его поля st_ctime и st_mtime устанавливаются в значение текущего времени.
Файлы в каталоге /proc/[pid]/fd представляют открытые файловые дескрипторы процесса с PID
равным pid. Файлы в каталоге /proc/[pid]/fdinfo представляют дополнительную информацию об
этих файловых дескрипторах. Подробное описание данных каталогов можно найти в proc(5).
В заголовочном файле Linux <asm/fcntl.h> не определён O_ASYNC; вместо него определён
синоним FASYNC (как в BSD).
Открытые файловые описания
The term open file description is the one used by POSIX to refer to the entries in the
system-wide table of open files. In other contexts, this object is variously also called
an "open file object", a "file handle", an "open file table entry", or—in kernel-developer
parlance—a struct file.
При создании копии файлового дескриптора (с помощью dup(2) или подобного вызова), копия
ссылается на то же открытое файловое описание что и изначальный файловый дескриптор, и,
следовательно, два файловых дескриптора имеют общее файловое смещение и флаги состояния
файла. Такая общность может также быть у двух процессов: процесс-потомок, создаваемый
fork(2), наследует копии файловых дескрипторов своего родителя и эти копии ссылаются на те
же открытые файловые описания.
При каждом open() файла создаётся новое файловое описание; таким образом, может быть
несколько открытых файловых описаний, соответствующих inode файла.
Для проверки того, что два файловых дескриптора (одного процесса или разных) ссылаются на
одно файловое описание, в Linux можно использовать вызов kcmp(2) с операцией KCMP_FILE.
Синхронизированный ввод-вывод
В POSIX.1-2008 способность «синхронизированного ввода-вывода» описана в виде различных
вариантов синхронизированного ввода-вывода и для open() определяет флаги управления
поведением O_SYNC, O_DSYNC и O_RSYNC. Независимо от того, имеется ли в реализации данная
способность, она должна, как минимум, поддерживать использование флага O_SYNC для обычных
файлов.
В Linux реализованы O_RSYNC и O_DSYNC, но не O_RSYNC. Несколько некорректно в glibc
определён O_RSYNC со значением как у O_SYNC (O_RSYNC определён в заголовочном файле Linux
<asm/fcntl.h> для HP PA-RISC, но не используется).
Флаг O_SYNC предоставляет выполнение целостного синхронизованного ввод-вывода file, то
есть операции записи передают данные и все связанные метаданные в задействованное
аппаратное обеспечение. Флаг O_DSYNC предоставляет выполнение целостного синхронизованного
ввод-вывода data, то есть операции записи передают данные в задействованное аппаратное
обеспечение, но обновляются только те метаданные, которые требуются для выполнения
последующего чтения. Полнота целостности данных может сократить количество дисковых
операций, которые требуются приложениям, не требующим гарантий целостности файлов.
Чтобы понять разницу между двумя типами обеспечения целостности рассмотрим две части
метаданных файла: метка времени последнего изменения файла (st_mtime) и длину файла. Все
операции записи обновляют метку времени последнего изменения файла, но только при записи,
которая добавляет данные в конец файла, будет изменена длина файла. Метка времени
последнего изменения файла не требуется для корректного чтения файла, чего не скажешь о
длине. Таким образом, O_DSYNC гарантирует только запись обновлений о метаданных длины
файла (в то время как O_SYNC также всегда записывает метаданные о метки времени последнего
изменения файла).
До Linux версии 2.6.33 в Linux реализован только флаг O_SYNC для open(). Однако, когда
этот флаг указан, большинство файловых систем в действительности предоставляют эквивалент
выполнения целостности синхронизированного ввода-вывода data (т. е., на самом деле O_SYNC
был реализован как эквивалент O_DSYNC).
Since Linux 2.6.33, proper O_SYNC support is provided. However, to ensure backward binary
compatibility, O_DSYNC was defined with the same value as the historical O_SYNC, and
O_SYNC was defined as a new (two-bit) flag value that includes the O_DSYNC flag value.
This ensures that applications compiled against new headers get at least O_DSYNC semantics
before Linux 2.6.33.
Отличия между библиотекой C и ядром
Since glibc 2.26, the glibc wrapper function for open() employs the openat() system
call, rather than the kernel's open() system call. For certain architectures, this is
also true before glibc 2.26.
NFS
В протоколе, по которому работает NFS, существует множество недоработок, оказывающих
влияние на многое, в том числе на работу с O_SYNC и O_NDELAY.
В файловых системах NFS с включённым проецированием UID, open() может вернуть файловый
дескриптор, но, например, запросы read(2) будут отклонены с ошибкой EACCES. Это происходит
из-за того, что клиент выполняет open() проверяя одни права, но сервер выполняет
проецирование UID только при запросах чтения и записи.
FIFO
Открытие на чтение или запись конца FIFO приводит к блокировке то тех пор, пока другой
конец не также не будет открыт (другим процессом или нитью). Подробности смотрите в
fifo(7).
Режим доступа к файлу
В отличие от других значений, указываемых в flags, значения режима доступа O_RDONLY,
O_WRONLY и O_RDWR, не определяются отдельными битами. Точнее, они задаются двумя первыми
битами flags, и имеют значения 0, 1 и 2, соответственно. Другими словами, комбинация
O_RDONLY | O_WRONLY приводит к логической ошибке и точно не работает как O_RDWR.
В Linux зарезервирован специальный нестандартный режим доступа 3 (11 двоичное) в flags,
при котором: проверяются права на чтение и запись к файлу и возвращается файловый
дескриптор, который не может использоваться для чтения или записи. Данный нестандартный
режим доступа используется некоторыми драйверами Linux для получения файлового
дескриптора, который будет использоваться в ioctl(2) только для специальных операций с
устройством.
Обоснование openat() и остального программного интерфейса файлового дескриптора каталога
openat() and the other system calls and library functions that take a directory file
descriptor argument (i.e., execveat(2), faccessat(2), fanotify_mark(2), fchmodat(2),
fchownat(2), fspick(2), fstatat(2), futimesat(2), linkat(2), mkdirat(2), mknodat(2),
mount_setattr(2), move_mount(2), name_to_handle_at(2), open_tree(2), openat2(2),
readlinkat(2), renameat(2), renameat2(2), statx(2), symlinkat(2), unlinkat(2),
utimensat(2), mkfifoat(3), and scandirat(3)) address two problems with the older
interfaces that preceded them. Here, the explanation is in terms of the openat() call,
but the rationale is analogous for the other interfaces.
Во-первых, openat() позволяет приложению избежать условий состязательности, которые могут
возникнуть, когда open() открывает файлы в каталогах, отличных от текущего рабочего
каталога. Состязательность возникает из-за того, что один из компонентов префикса
каталога, указанного open(), может измениться одновременно с вызовом open(). Например,
предположим, что мы хотим создать файл dir1/dir2/xxx.dep и существует файл dir1/dir2/xxx.
Проблема находится между шагами проверки существования и созданием файла, указываемые dir1
или dir2 (которые могут быть символическими ссылками) места могут измениться. Этой
состязательности можно избежать открыв файловый дескриптор каталога назначения, и затем
указав этот файловый дескриптор в аргументе dirfd вызова (скажем) fstatat(2) и openat().
Также, использование файлового дескриптора dirfd имеет другие преимущества:
• файловый дескриптор — это стабильная ссылка на каталог, даже если каталог будет
переименован; и
• открытый файловый дескриптор предотвращает размонтирование нижележащей файловой системы
также, как если бы каталог являлся текущим рабочим каталогом процесса в файловой
системе.
Во-вторых, openat() позволяет реализовать отдельный «текущий рабочий каталог» для каждой
нити посредством файлового дескриптора, сопровождаемого приложением. Эта возможность также
может быть получена с использованием /proc/self/fd/dirfd, но менее эффективно.
The dirfd argument for these APIs can be obtained by using open() or openat() to open a
directory (with either the O_RDONLY or the O_PATH flag). Alternatively, such a file
descriptor can be obtained by applying dirfd(3) to a directory stream created using
opendir(3).
When these APIs are given a dirfd argument of AT_FDCWD or the specified pathname is
absolute, then they handle their pathname argument in the same way as the corresponding
conventional APIs. However, in this case, several of the APIs have a flags argument that
provides access to functionality that is not available with the corresponding conventional
APIs.
O_DIRECT
The O_DIRECT flag may impose alignment restrictions on the length and address of
user-space buffers and the file offset of I/Os. In Linux alignment restrictions vary by
filesystem and kernel version and might be absent entirely. The handling of misaligned
O_DIRECT I/Os also varies; they can either fail with EINVAL or fall back to buffered I/O.
Since Linux 6.1, O_DIRECT support and alignment restrictions for a file can be queried
using statx(2), using the STATX_DIOALIGN flag. Support for STATX_DIOALIGN varies by
filesystem; see statx(2).
Some filesystems provide their own interfaces for querying O_DIRECT alignment
restrictions, for example the XFS_IOC_DIOINFO operation in xfsctl(3). STATX_DIOALIGN
should be used instead when it is available.
If none of the above is available, then direct I/O support and alignment restrictions can
only be assumed from known characteristics of the filesystem, the individual file, the
underlying storage device(s), and the kernel version. In Linux 2.4, most filesystems
based on block devices require that the file offset and the length and memory address of
all I/O segments be multiples of the filesystem block size (typically 4096 bytes). In
Linux 2.6.0, this was relaxed to the logical block size of the block device (typically 512
bytes). A block device's logical block size can be determined using the ioctl(2)
BLKSSZGET operation or from the shell using the command:
blockdev --getss
Ввод-вывод с O_DIRECT никогда не должен запускаться одновременно с системным вызовом
fork(2), если буфер памяти является закрытым отображением (т. е., любым отображениям,
созданным с помощью mmap(2) с флагом MAP_PRIVATE; к ним относится память, выделенная под
кучу и статически выделенные буферы). Любой подобный ввод-вывод, предоставленный через
асинхронный интерфейс или из другой нити процесса, должен выполниться полностью до вызова
fork(2). В противном случае, может произойти повреждение данных и непредсказуемое
поведение в процессе родителя и потомка.Данное ограничение не действует, если буфер памяти
для ввода-вывода с O_DIRECT был создан с помощью shmat(2) или mmap(2) с флагом MAP_SHARED.
И при этом это ограничение не действует, когда буфер памяти был помечен (advised) как
MADV_DONTFORK с помощью madvise(2), если точно известно, что он не будет доступен потомку
после fork(2).
Флаг O_DIRECT появился в SGI IRIX, где ограничения на выравнивание подобны Linux 2.4. В
IRIX также есть вызов fcntl(2) для запроса значений соответствующего выравнивания и
размеров. В FreeBSD 4.x появился флаг с таким же именем, но без ограничений на
выравнивание.
O_DIRECT support was added in Linux 2.4.10. Older Linux kernels simply ignore this flag.
Some filesystems may not implement the flag, in which case open() fails with the error
EINVAL if it is used.
Приложения должны избегать смешивания O_DIRECT и обычных операций ввода-вывода в один файл
и особенно перекрывать байтовые области. Даже когда файловая система правильно
обрабатывает проблемы с когерентностью в такой ситуации, общая пропускная способность
ввода-вывода, вероятно, будет медленнее чем при использовании какого-то одного из этих
режимов отдельно. Аналогично приложения должны избегать смешивания mmap(2) и прямого
ввода-вывода для одинаковых файлов.
Поведение O_DIRECT на NFS отличается от локальных файловых систем. Старые ядра и ядра,
настроенные определёнными способами, могут не поддерживать такую комбинацию. Протокол NFS
не поддерживает передачу флага на сервер, поэтому ввод-вывод с O_DIRECT будет пропускать
кэширование страниц только на клиенте; сервер всё равно может выполнить кэширование
ввода-вывода. Клиент просит сервер выполнять операции ввода-вывода синхронно для
сохранения синхронной семантики O_DIRECT. Некоторые серверы будут выполнять это плохо при
определённых условиях, особенно если размер данных ввода-вывода невелик. Некоторые серверы
также могут быть настроены на отправку ложного ответа клиентам о том, что ввод-вывод
произведён на носитель; это позволяет избежать потери производительности, но есть риск
потери целостности данных в случае проблем с электропитанием сервера. В Linux клиент NFS
не устанавливает ограничений по выравниванию при вводе-выводе с O_DIRECT.
Флаг O_DIRECT является потенциально мощным инструментом, который нужно использовать с
осторожностью. Рекомендуется, чтобы приложения считали использование O_DIRECT как параметр
производительности, который по умолчанию выключен.
ДЕФЕКТЫ
На данный момент невозможно включить сигнальное управление вводом-выводом, указав O_ASYNC
при вызове open(); чтобы установить этот флаг используйте fcntl(2).
Для определения поддержки ядром O_TMPFILE нужно проверять два различных кода ошибок —
EISDIR и ENOENT.
При указании флагов O_CREAT и O_DIRECTORY в flags, и при этом указанный в pathname файл не
существует, open() создаст обычный файл (то есть флаг O_DIRECTORY будет проигнорирован).
СМ. ТАКЖЕ
chmod(2), chown(2), close(2), dup(2), fcntl(2), link(2), lseek(2), mknod(2), mmap(2),
mount(2), open_by_handle_at(2), openat2(2), read(2), socket(2), stat(2), umask(2),
unlink(2), write(2), fopen(3), acl(5), fifo(7), inode(7), path_resolution(7), symlink(7)
ПЕРЕВОД
Русский перевод этой страницы руководства был сделан Azamat Hackimov
<azamat.hackimov@gmail.com>, Konstantin Shvaykovskiy <kot.shv@gmail.com>, Yuri Kozlov
<yuray@komyakino.ru> и Иван Павлов <pavia00@gmail.com>
Этот перевод является бесплатной документацией; прочитайте Стандартную общественную
лицензию GNU версии 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ или более позднюю, чтобы
узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ.
Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте
электронное письмо на ⟨man-pages-ru-talks@lists.sourceforge.net⟩.