ИМЯ

open, openat, creat - открывает и, возможно, создаёт файл

ОБЗОР

#include <sys/types.h>
#include <sys/stat.h>
#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);

Требования макроса тестирования свойств для glibc (см. feature_test_macros(7)):

openat():
Начиная с glibc 2.10:
_POSIX_C_SOURCE >= 200809L
До glibc 2.10:
_ATFILE_SOURCE

ОПИСАНИЕ

Получив в pathname имя файла, open() возвращает файловый дескриптор — небольшое,
неотрицательное значение — для использования в последующих системных вызовах
(read(2), write(2), lseek(2), fcntl(2) и т.д.). Файловый дескриптор, возвращаемый
при успешном выполнении вызова, будет самым маленьким числом из файловых
дескрипторов, которые ещё не открыты процессом.

По умолчанию, новый файловый дескриптор остаётся открытым при вызове 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
Включает ввод-вывод, управляемый сигналом: генерирует сигнал (по умолчанию
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
Если файл не существует, то он будет создан.

Владельцем (ID пользователя) нового файла назначается эффективный
идентификатор пользователя процесса.

Группой владельцев (ID группы) нового файла назначается эффективный
идентификатор группы процесса (согласно System V) или ID группы
родительского каталога (согласно BSD). В Linux это зависит от наличия бита
режима set-group-ID на родительском каталоге: если этот бит установлен, то
используется правило BSD; в противном случае применяется правило System V.
В некоторых файловых системах поведение также зависит от параметров
монтирования bsdgroups и sysvgroups, описанных в mount(8)).

В аргументе mode указываются биты файлового режима, которые используются
при создании нового файла. Этот параметр должен указываться, если в flags
устанавливается O_CREAT или O_TMPFILE; если O_CREAT или O_TMPFILE не
указаны, то mode игнорируется. Эффективный режим изменяется согласно umask
процесса как обычно: в случае отсутствия списков доступа по умолчанию режим
созданного файла будет установлен согласно (mode & ~umask). Заметим, что
этот режим будет учтён только при последующих обращениях к созданному
файлу; вызов open(), создающий файл только для чтения, может вернуть
файловый дескриптор доступный на чтение и запись.

Символьные константы, используемые в mode:

S_IRWXU 00700 пользователь (владелец файла) имеет права на чтение, запись
и выполнение файла

S_IRUSR 00400 пользователь имеет права на чтение файла

S_IWUSR 00200 пользователь имеет права на запись в файл


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 bit (см. stat(2))

S_ISVTX 0001000 закрепляющий бит (см. stat(2))

O_DIRECT (начиная с Linux 2.4.10)
Попытаться минимизировать влияние кэширования ввода-вывода при чтении и
записи в файл. Обычно, это ухудшает производительность, но полезно для
особых случаев, например, когда приложение выполняет кэширование
самостоятельно. Файловый ввод-вывод выполняется непосредственно в/из
буферов пространства пользователя. При флаге O_DIRECT предпринимаются все
усилия для синхронной передачи данных, но это не гарантирует, как с флагом
O_SYNC, передачу данных и необходимых метаданных. Чтобы гарантировать
синхронный ввод-вывод вместе с O_DIRECT нужно использовать O_SYNC.
Дальнейшее описание смотрите далее в разделе ЗАМЕЧАНИЯ.

Семантически похожий интерфейс (но устаревший) для блочных устройств описан
в raw(8).

O_DIRECTORY
Если pathname не является каталогом, то завершить вызов с ошибкой. Этот
флаг был добавлен в ядро версии 2.1.126, чтобы избежать проблем с «отказом
в обслуживании», если opendir(3) был вызван для канала FIFO или ленточного
устройства.

O_DSYNC
Операции записи файла будут выполнены согласно требованиям целостности
синхронизации ввода-вывода data.

К времени возврата из write(2) (и подобных) выходные данные уже переданы в
задействованное аппаратное обеспечение вместе со всеми метаданными файла,
которые бы потребовались для получения данных (т. е., как если бы за каждым
write(2) был выполнен вызов fdatasync(2)). Смотрите ЗАМЕЧАНИЯ далее.

O_EXCL Гарантирует, что вызов создаст файл: если этот флаг указан вместе с O_CREAT
и pathname уже существует, то open() завершится с ошибкой.

При использовании обоих флагов символьные ссылки не поддерживаются: если
pathname является символьной ссылкой, то open() завершается с ошибкой
независимо от того, куда указывает ссылка.

Вообще говоря, поведение с O_EXCL не определено, если этот флаг
используется без O_CREAT. Есть одно исключение: в Linux 2.6 и более новых
избегать зависимости от поддержки в 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
Если pathname указывает на терминальное устройство (см. tty(4)), то оно не
станет управляющим терминалом процесса, даже если процесс такового не
имеет.

O_NOFOLLOW
Если pathname является символьной ссылкой, то открытие завершится неудачно.
Это расширение FreeBSD, которое было добавлено в Linux версии 2.1.126. Все
прочие символьные ссылки в имени будут обработаны как обычно. Также
смотрите описание O_PATH далее.

O_NONBLOCK или O_NDELAY
Если возможно, файл открывается в неблокирующем режиме. Ни open(), ни
другие последующие операции над возвращаемым дескриптором файла не заставят
вызывающий процесс ждать.

Обратите внимание, что этот флаг не оказывает влияния на обычные файлы и
блочные устройства, то есть операции ввода-вывода будут блокироваться на
короткое время, если будет запрошено активность устройства, вне зависимости
от установки флага O_NONBLOCK. Семантика O_NONBLOCK может быть когда-нибудь
реализована, поэтому приложения не должны зависеть от блокировок при
работающих исключительно на уровне файловых дескрипторов. Сам файл не
открывается и другие файловые операции (например, read(2), write(2),
fchmod(2), fchown(2), fgetxattr(2), mmap(2)) завершатся с ошибкой EBADF.

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

* close(2); fchdir(2) (начиная с Linux 3.5); fstat(2) (начиная с Linux
3.6).

* Создание дубликата файлового дескриптора (dup(2), fcntl(2) F_DUPFD и
т.д.).

* Получение и установка флагов файловых дескрипторов (fcntl(2) F_GETFD и
F_SETFD).

* Получение флагов состояния открытого файла с помощью операции fcntl(2)
F_GETFL: в возвращаемые флаги будет включён бит O_PATH.

* Передача файлового дескриптора в аргументе dirfd для openat(2) и других
системных вызовов «*at()». К ним относится linkat(2) с флагом
AT_EMPTY_PATH (или через procfs с помощью AT_SYMLINK_FOLLOW) даже, если
файл не является каталогом.

* Передача файлового дескриптора в другой процесс через доменный сокет
UNIX (смотрите SCM_RIGHTS в unix(7)).

Если O_PATH указан в flags, то биты флагов, отличные от O_CLOEXEC,
O_DIRECTORYи O_NOFOLLOW, игнорируются.

Если pathname является символьной ссылкой и также указан флаг O_NOFOLLOW,
то вызов возвращает файловый дескриптор, указывающий на символьную ссылку.
Этот файловый дескриптор можно использовать в аргументе dirfd для вызовов
fchownat(2), fstatat(2), linkat(2) и readlinkat(2) с пустым именем пути,
чтобы выполнить операцию над символьной ссылкой.

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,

как с 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 и shmem.
Поддержка в XFS добавлена в Linux 3.15, а поддержка Btrfs и F2FS добавлена
в Linux 3.16.

O_TRUNC
Если файл уже существует и является обычным файлом и режим доступа
позволяет писать в этот файл (т.е. установлен флаг O_RDWR или O_WRONLY), то
его длина будет урезана до нуля. Если файл является FIFO или терминальным
устройством, то этот флаг игнорируется. В других случаях действие флага
O_TRUNC не определено.

creat()
Вызов creat() эквивалентен вызову open() с значением flags
O_CREAT|O_WRONLY|O_TRUNC.

openat()
Системный вызов openat() работает также как системный вызов open(), за исключением
случаев, описанных здесь.

Если в pathname задан относительный путь, то он считается относительно каталога,
на который ссылается файловый дескриптор dirfd (а не относительно текущего
рабочего каталога вызывающего процесса, как это делается в open()).

Если в pathname задан относительный путь и dirfd равно специальному значению
AT_FDCWD, то pathname рассматривается относительно текущего рабочего каталога
вызывающего процесса (как open()).

Если в pathname задан абсолютный путь, то dirfd игнорируется.

ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ

Вызовы open(), openat() и creat() возвращают новый дескриптор файла или -1 в
случае ошибки (в этом случае errno устанавливается в соответствующее значение).

ОШИБКИ

Вызовы open(), openat() и creat() могут завершаться со следующими ошибками:

EFAULT Аргумент pathname указывает за пределы доступного адресного пространства.

EFBIG Смотрите EOVERFLOW.

EINTR При блокирующем ожидании завершения открытия медленного устройства
(например, FIFO; см. fifo(7)), вызов был прерван обработчиком сигнала;
смотрите signal(7).

EINVAL Файловая система не поддерживает флаг O_DIRECT. Подробности смотрите в
ЗАМЕЧАНИЯ.

EINVAL Некорректное значение flags.

EINVAL В flags указан O_TMPFILE, но не указан O_WRONLY или O_RDWR.

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 не задан и файл с таким именем не существует, или же не
существует один из каталогов в pathname, или имеется повисшая символьная
ссылка.

ENOENT Значение pathname ссылается на несуществующий каталог, в flags указан
O_TMPFILE и один из O_WRONLY или O_RDWR, но версия ядра не предоставляет
свойство O_TMPFILE.

ENOMEM Недостаточное количество памяти ядра.

ENOSPC Файл pathname должен быть создан, но на устройстве его содержащем нет места
для нового файла.

ENOTDIR
Компонент, который обозначен как каталог в pathname, таковым не является,
или был указан флаг O_DIRECTORY, но pathname не является каталогом.

ENXIO Установлены O_NONBLOCK | O_WRONLY , именованный файл имеет тип FIFO и ни
pathname ссылается на обычный файл, который слишком велик для открытия.
Обычно, это случается когда приложение, скомпилированное на 31-битной
платформе без -D_FILE_OFFSET_BITS=64, пытается открыть файл размером более
(1<<31)-1 байт; смотрите также описание O_LARGEFILE ранее. Эта ошибка
определена в POSIX.1; в ядрах до версии 2.6.24 Linux в этом случае выдавал
ошибку EFBIG.

EPERM Задан флаг O_NOATIME, но эффективный ID пользователя вызывающего процесса
не совпадает с владельцем файла и вызывающий не имеет прав.

EPERM Выполнение операции предотвращено опечатыванием (file seal); смотрите
fcntl(2).

EROFS pathname указывает на файл на файловой системе, доступной только на чтение,
но запрашивается доступ на запись.

ETXTBSY
pathname указывает на исполняемый файл, который запущен в данный момент, но
запрашивается доступ на запись.

EWOULDBLOCK
Указан флаг O_NONBLOCK, но несовместимая аренда (lease) удерживает файл
(смотрите fcntl(2)).

В openat() дополнительно могут возникнуть следующие ошибки:

EBADF dirfd не является правильным файловым дескриптором.

ENOTDIR
Значение pathname содержит относительный путь и dirfd содержит файловый
дескриптор, указывающий на файл, а не на каталог.

ВЕРСИИ

Вызов openat() был добавлен в ядро Linux версии 2.6.16; поддержка в glibc доступна
с версии 2.4.

СООТВЕТСТВИЕ СТАНДАРТАМ

open(), creat() SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.

openat(): POSIX.1-2008.

Флаги 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 указывает, что файл нужно открыть, но не обязательно будет
производиться чтение или запись. Обычно это указывается для открытия устройства,
последнего доступа, последней смены состояния и последнего изменения,
соответственно; см. stat(2)) устанавливаются в значение текущего времени, и оно
совпадает с полями st_ctime и st_mtime родительского каталога. Или же, если файл
изменяется из-за установленного флага O_TRUNC, то его поля st_ctime и st_mtime
устанавливаются в значение текущего времени.

Файлы в каталоге /proc/[pid]/fd представляют открытые файловые дескрипторы
процесса с PID равным pid. Файлы в каталоге /proc/[pid]/fdinfo представляют
дополнительную информацию об этих файловых дескрипторах. Подробное описание данных
каталогов можно найти в proc(5).

Открытые файловые описания
Термин «открытое файловое описание» (open file description) используется в POSIX
для указания на записи в системной таблице открытых файлов. В других контекстах,
этот объект также называется «открытый файловый объект» (open file object),
«описатель файла» (file handle), «»табличная запись открытого файла (open file
table entry) или 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_SYNC и O_DSYNC, но не O_RSYNC (немного некорректно, в glibc
определён O_RSYNC со значением как у O_SYNC).

Флаг O_SYNC предоставляет выполнение целостного синхронизованного ввод-вывода
file, то есть операции записи передают данные и все связанные метаданные в
задействованное аппаратное обеспечение. Флаг O_DSYNC предоставляет выполнение
целостного синхронизованного ввод-вывода data, то есть операции записи передают
данные в задействованное аппаратное обеспечение, но обновляются только те
метаданные, которые требуются для выполнения последующего чтения. Полнота
целостности данных может сократить количество дисковых операций, которые требуются
приложениям, не требующим гарантий целостности файлов.

Чтобы понять разницу между двумя типами обеспечения целостности рассмотрим две
части метаданных файла: метка времени последнего изменения файла (st_mtime) и
длину файла. Все операции записи обновляют метку времени последнего изменения
файла, но только при записи, которая добавляет данные в конец файла, будет
изменена длина файла. Метка времени последнего изменения файла не требуется для

Начиная с Linux 2.6.33, предоставляет корректная поддержка O_SYNC. Однако для
обеспечения обратной двоичной совместимости, O_DSYNC был определён с тем же
значением что и старый O_SYNC, а O_SYNC был определён как новое значение флага
(два бита), которое включает значение флага O_DSYNC. Это позволяет приложениям,
скомпилированным с новыми заголовочными файлами получать, по крайней мере,
семантику O_DSYNC ядер pre-2.6.33.

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() и другие системные вызовы и библиотечные функции, которые
используют файловый дескриптор каталога в качестве аргумента (т. е., execveat(2),
faccessat(2), fanotify_mark(2), fchmodat(2), fchownat(2), fstatat(2),
futimesat(2), linkat(2), mkdirat(2), mknodat(2), name_to_handle_at(2),
readlinkat(2), renameat(2), symlinkat(2), unlinkat(2), utimensat(2) mkfifoat(3) и
scandirat(3)) поддерживаются по двум причинам. Вот объяснение применимое к вызову
openat(), но объяснение для других интерфейсов аналогично.

Во-первых, openat() позволяет приложению избежать условий состязательности,
которые могут возникнуть, когда open() открывает файлы в каталогах, отличных от
текущего рабочего каталога. Состязательность возникает из-за того, что один из
компонентов префикса каталога, указанного open(), может измениться одновременно с
вызовом open(). Например, предположим, что мы хотим создать файл path/to/xxx.dep и
существует файл path/to/xxx. Проблема находится между шагами проверки
существования и созданием файла, указываемые path или to (которые могут быть
символическими ссылками) места могут измениться. Этой состязательности можно
избежать открыв файловый дескриптор каталога назначения, и затем указав этот
файловый дескриптор в аргументе dirfd вызова (скажем) fstatat(2) и openat().

даже могут отсутствовать. Однако сейчас не существует независимого от файловой
системы интерфейса приложения для выявления этих ограничений на определённый файл
или файловую систему. Некоторые файловые системы предоставляют свои собственные
интерфейсы для этого, например, операция XFS_IOC_DIOINFO в xfsctl(3).

В Linux 2.4 размеры передачи, выравнивание пользовательского буфера и файлового
смещения должны быть кратны размеру логического блока файловой системы. Начиная с
Linux 2.6 достаточно выравнивания по 512-байтовой границе. Размер логического
блока можно определить с помощью ioctl(2) и операции BLKSSZGET или с помощью
команды:

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 добавлена в ядро Linux версии 2.4.10. Более старые ядра Linux
просто игнорируют этот флаг. В некоторых файловых системах этот флаг может быть не
реализован и open() завершится с ошибкой EINVAL при его использовании.

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

Поведение O_DIRECT на NFS отличается от локальных файловых систем. Старые ядра и
ядра, настроенные определёнными способами, могут не поддерживать такую комбинацию.
Протокол NFS не поддерживает передачу флага на сервер, поэтому ввод-вывод с
O_DIRECT будет пропускать кэширование страниц только на клиенте; сервер всё равно
может выполнить кэширование ввода-вывода. Клиент просит сервер выполнять операции
ввода-вывода синхронно для сохранения синхронной семантики O_DIRECT. Некоторые
серверы будут выполнять это плохо при определённых условиях, особенно если размер
данных ввода-вывода невелик. Некоторые серверы также могут быть настроены на
отправку ложного ответа клиентам о том, что ввод-вывод произведён на носитель; это
позволяет избежать потери производительности, но есть риск потери целостности
данных в случае проблем с электропитанием сервера. В Linux клиент NFS не
устанавливает ограничений по выравниванию при вводе-выводе с 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), read(2), socket(2), stat(2), umask(2),
unlink(2), write(2), fopen(3), acl(5), fifo(7), path_resolution(7), symlink(7)