.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson. .\" and Copyright (C) 2008 Greg Banks .\" and Copyright (C) 2006, 2008, 2013, 2014 Michael Kerrisk .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" Modified 1993-07-21 by Rik Faith .\" Modified 1994-08-21 by Michael Haardt .\" Modified 1996-04-13 by Andries Brouwer .\" Modified 1996-05-13 by Thomas Koenig .\" Modified 1996-12-20 by Michael Haardt .\" Modified 1999-02-19 by Andries Brouwer .\" Modified 1998-11-28 by Joseph S. Myers .\" Modified 1999-06-03 by Michael Haardt .\" Modified 2002-05-07 by Michael Kerrisk .\" Modified 2004-06-23 by Michael Kerrisk .\" 2004-12-08, mtk, reordered flags list alphabetically .\" 2004-12-08, Martin Pool (& mtk), added O_NOATIME .\" 2007-09-18, mtk, Added description of O_CLOEXEC + other minor edits .\" 2008-01-03, mtk, with input from Trond Myklebust .\" and Timo Sirainen .\" Rewrite description of O_EXCL. .\" 2008-01-11, Greg Banks : add more detail .\" on O_DIRECT. .\" 2008-02-26, Michael Haardt: Reorganized text for O_CREAT and mode .\" .\" FIXME . Apr 08: The next POSIX revision has O_EXEC, O_SEARCH, and .\" O_TTYINIT. Eventually these may need to be documented. --mtk .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH OPEN 2 "1 ноября 2020 г." Linux "Руководство программиста Linux" .SH ИМЯ open, openat, creat \- открывает и, возможно, создаёт файл .SH СИНТАКСИС .nf \fB#include \fP \fB#include \fP \fB#include \fP .PP \fBint open(const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB);\fP \fBint open(const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB, mode_t \fP\fImode\fP\fB);\fP .PP \fBint creat(const char *\fP\fIpathname\fP\fB, mode_t \fP\fImode\fP\fB);\fP .PP \fBint openat(int \fP\fIdirfd\fP\fB, const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB);\fP \fBint openat(int \fP\fIdirfd\fP\fB, const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB, mode_t \fP\fImode\fP\fB);\fP .PP /* Documented separately, in \fBopenat2\fP(2): */ \fBint openat2(int \fP\fIdirfd\fP\fB, const char *\fP\fIpathname\fP\fB,\fP \fB const struct open_how *\fP\fIhow\fP\fB, size_t \fP\fIsize\fP\fB);\fP .fi .PP .RS -4 Требования макроса тестирования свойств для glibc (см. \fBfeature_test_macros\fP(7)): .RE .PP \fBopenat\fP(): .PD 0 .ad l .RS 4 .TP 4 Начиная с glibc 2.10: _POSIX_C_SOURCE\ >=\ 200809L .TP До glibc 2.10: _ATFILE_SOURCE .RE .ad .PD .SH ОПИСАНИЕ Системный вызов \fBopen\fP() открывает файл, на который указывает \fIpathname\fP. Если заданный файл не существует, то он может быть создан \fBopen\fP() (если в \fIflags\fP задан \fBO_CREAT\fP). .PP Возвращаемым значением \fBopen\fP() является файловый дескриптор, указывающий на открытый файл — небольшое неотрицательное целое, которое используется в последующих системных вызовах (\fBread\fP(2), \fBwrite\fP(2), \fBlseek\fP(2), \fBfcntl\fP(2) и т. д.). Файловый дескриптор, возвращаемый при успешном выполнении вызова, будет самым маленьким числом из файловых дескрипторов, которые ещё не открыты процессом. .PP По умолчанию, новый файловый дескриптор остаётся открытым при вызове \fBexecve\fP(2) (т. е., флаг \fBFD_CLOEXEC\fP файлового дескриптора, описанный в \fBfcntl\fP(2), изначально сброшен; для изменения поведения по умолчанию можно использовать флаг \fBO_CLOEXEC\fP, он описан далее). Файловое смещение устанавливается на начало файла (см. \fBlseek\fP(2)). .PP Вызов \fBopen\fP() создаёт новое \fIоткрытое файловое описание\fP — запись в системной таблице открытых файлов. В этой записи хранится смещение и флаги состояния файла (смотрите ниже). Файловый дескриптор — это ссылка на открытое файловое описание; с этой ссылкой ничего не происходит при последующем удалении \fIpathname\fP или переуказании имени на другой файл. Дополнительную информацию об открытых файловых описаниях смотрите в разделе ЗАМЕЧАНИЯ. .PP Параметр \fIflags\fP должен содержать один из следующих \fIрежимов доступа\fP: \fBO_RDONLY\fP (только для чтения), \fBO_WRONLY\fP (только для записи) или \fBO_RDWR\fP (для чтения и записи). .PP .\" SUSv4 divides the flags into: .\" * Access mode .\" * File creation .\" * File status .\" * Other (O_CLOEXEC, O_DIRECTORY, O_NOFOLLOW) .\" though it's not clear what the difference between "other" and .\" "File creation" flags is. I raised an Aardvark to see if this .\" can be clarified in SUSv4; 10 Oct 2008. .\" http://thread.gmane.org/gmane.comp.standards.posix.austin.general/64/focus=67 .\" TC1 (balloted in 2013), resolved this, so that those three constants .\" are also categorized" as file status flags. .\" Также в \fIflags\fP можно указывать флаги создания и состояния файла, объединяя их битовой операцией \fIИЛИ\fP. \fIФлаги создания файла\fP: \fBO_CLOEXEC\fP, \fBO_CREAT\fP, \fBO_DIRECTORY\fP, \fBO_EXCL\fP, \fBO_NOCTTY\fP, \fBO_NOFOLLOW\fP, \fBO_TMPFILE\fP и \fBO_TRUNC\fP. \fIФлаги состояния файла\fP — все оставшиеся, перечислены ниже. Различие между двумя этими группами в том, что флаги создания влияют на работу самой операции открытия, а флаги состояния влияют на работу последующих операций ввода\-вывода. Флаги состояния можно запросить и (в некоторых случаях) изменить; смотрите \fBfcntl\fP(2). .PP Полный список флагов создания и флагов состояния файла: .TP \fBO_APPEND\fP Файл открывается в режиме добавления. Перед каждым вызовом \fBwrite\fP(2), файловое смещение устанавливается в конец файла, как если бы это делалось с помощью \fBlseek\fP(2). Изменение файлового смещения и операция записи выполняются атомарно, за один шаг. .IP .\" For more background, see .\" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453946 .\" http://nfs.sourceforge.net/ Указание флага \fBO_APPEND\fP может приводить к повреждению файлов в файловых системах NFS, если одновременно добавляют данные в файл несколько процессов. Это происходит из\-за того, что NFS не поддерживает добавление в файл, поэтому клиентское ядро имитирует такое поведение, но при этом нельзя избежать состязательности процессов. .TP \fBO_ASYNC\fP Включает ввод\-вывод, управляемый сигналом: генерирует сигнал (по умолчанию \fBSIGIO\fP, но можно изменить с помощью \fBfcntl\fP(2)), когда становится возможным ввод или вывод для этого файлового дескриптора. Эта возможность доступна только для терминалов, псевдотерминалов, сокетов, каналов (начиная с Linux 2.6) и FIFO. Подробней смотрите \fBfcntl\fP(2). Также смотрите ДЕФЕКТЫ далее. .TP \fBO_CLOEXEC\fP (начиная с Linux 2.6.23) .\" NOTE! several other man pages refer to this text .\" FIXME . for later review when Issue 8 is one day released... .\" POSIX proposes to fix many APIs that provide hidden FDs .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8 .\" http://austingroupbugs.net/view.php?id=368 Устанавливает флаг close\-on\-exec на новом файловом дескрипторе. Указание данного флага позволяет программе избежать дополнительной операции \fBfcntl\fP(2) \fBF_SETFD\fP для установки флага \fBFD_CLOEXEC\fP. .IP .\" This flag fixes only one form of the race condition; .\" The race can also occur with, for example, file descriptors .\" returned by accept(), pipe(), etc. Заметим, что использование этого флага обязательно для некоторых многонитиевых программ, так как использование отдельной операции \fBfcntl\fP(2) \fBF_SETFD\fP для установки флага \fBFD_CLOEXEC\fP недостаточно для избежания состязательности, когда одна нить открывает файловый дескриптор, а в тоже время другая нить может выполнять \fBfork\fP(2) и \fBexecve\fP(2). В зависимости от порядка выполнения, состязательность может привести к тому, что файловый дескриптор, возвращённый \fBopen\fP(), будет ненамеренно передан программе, выполняющейся в созданном с помощью \fBfork\fP(2) потомке (такого рода состязательность, в принципе, возможна для любых системных вызовов, создающих файловый дескриптор, у которого должен быть установлен флаг close\-on\-exec, и различные другие системные вызовы Linux предоставляют эквивалент флагу \fBO_CLOEXEC\fP, чтобы избежать этой проблемы). .TP \fBO_CREAT\fP Если \fIpathname\fP не существует, то создать обычный файл. .IP Владельцем (ID пользователя) нового файла назначается эффективный идентификатор пользователя процесса. .IP .\" As at 2.6.25, bsdgroups is supported by ext2, ext3, ext4, and .\" XFS (since 2.6.14). Группой владельцев (ID группы) нового файла назначается эффективный идентификатор группы процесса (согласно System V) или ID группы родительского каталога (согласно BSD). В Linux это зависит от наличия бита режима set\-group\-ID на родительском каталоге: если этот бит установлен, то используется правило BSD; в противном случае применяется правило System V. В некоторых файловых системах поведение также зависит от параметров монтирования \fIbsdgroups\fP и \fIsysvgroups\fP, описанных в \fBmount\fP(8). .IP The \fImode\fP argument specifies the file mode bits to be applied when a new file is created. If neither \fBO_CREAT\fP nor \fBO_TMPFILE\fP is specified in \fIflags\fP, then \fImode\fP is ignored (and can thus be specified as 0, or simply omitted). The \fImode\fP argument \fBmust\fP be supplied if \fBO_CREAT\fP or \fBO_TMPFILE\fP is specified in \fIflags\fP; if it is not supplied, some arbitrary bytes from the stack will be applied as the file mode. .IP The effective mode is modified by the process's \fIumask\fP in the usual way: in the absence of a default ACL, the mode of the created file is \fI(mode\ &\ \(tiumask)\fP. .IP Note that \fImode\fP applies only to future accesses of the newly created file; the \fBopen\fP() call that creates a read\-only file may well return a read/write file descriptor. .IP Символьные константы, используемые в \fImode\fP: .RS .TP 9 \fBS_IRWXU\fP 00700 пользователь (владелец файла) имеет права на чтение, запись и выполнение файла .TP \fBS_IRUSR\fP 00400 пользователь имеет права на чтение файла .TP \fBS_IWUSR\fP 00200 пользователь имеет права на запись в файл .TP \fBS_IXUSR\fP 00100 пользователь имеет права на выполнение файла .TP \fBS_IRWXG\fP 00070 группа имеет права на чтение, запись и выполнение файла .TP \fBS_IRGRP\fP 00040 группа имеет права на чтение файла .TP \fBS_IWGRP\fP 00020 группа имеет права на запись в файл .TP \fBS_IXGRP\fP 00010 группа имеет права на выполнение файла .TP \fBS_IRWXO\fP 00007 все остальные имеют права на чтение, запись и выполнение файла .TP \fBS_IROTH\fP 00004 все остальные имеют права на чтение файла .TP \fBS_IWOTH\fP 00002 все остальные имеют права на запись в файл .TP \fBS_IXOTH\fP 00001 все остальные имеют права на выполнение файла .RE .IP Согласно POSIX, в случае, если в \fImode\fP указаны другие биты, их воздействие не определено. В Linux для \fImode\fP также доступны следующие биты: .RS .TP 9 \fBS_ISUID\fP 0004000 бит set\-user\-ID .TP \fBS_ISGID\fP 0002000 бит set\-group\-ID (смотрите \fBinode\fP(7)). .TP \fBS_ISVTX\fP 0001000 закрепляющий бит bit (смотрите \fBinode\fP(7)). .RE .TP \fBO_DIRECT\fP (начиная с Linux 2.4.10) Попытаться минимизировать влияние кэширования ввода\-вывода при чтении и записи в файл. Обычно, это ухудшает производительность, но полезно для особых случаев, например, когда приложение выполняет кэширование самостоятельно. Файловый ввод\-вывод выполняется непосредственно в/из буферов пространства пользователя. При флаге \fBO_DIRECT\fP предпринимаются все усилия для синхронной передачи данных, но это не гарантирует, как с флагом \fBO_SYNC\fP, передачу данных и необходимых метаданных. Чтобы гарантировать синхронный ввод\-вывод вместе с \fBO_DIRECT\fP нужно использовать \fBO_SYNC\fP. Дальнейшее описание смотрите далее в разделе ЗАМЕЧАНИЯ. .IP Семантически похожий интерфейс (но устаревший) для блочных устройств описан в \fBraw\fP(8). .TP \fBO_DIRECTORY\fP .\" But see the following and its replies: .\" http://marc.theaimsgroup.com/?t=112748702800001&r=1&w=2 .\" [PATCH] open: O_DIRECTORY and O_CREAT together should fail .\" O_DIRECTORY | O_CREAT causes O_DIRECTORY to be ignored. Если \fIpathname\fP не является каталогом, то завершить вызов с ошибкой. Этот флаг был добавлен в ядро версии 2.1.126, чтобы избежать проблем с «отказом в обслуживании», если \fBopendir\fP(3) был вызван для канала FIFO или ленточного устройства. .TP \fBO_DSYNC\fP Операции записи файла будут выполнены согласно требованиям целостности синхронизации ввода\-вывода \fIdata\fP. .IP К времени возврата из \fBwrite\fP(2) (и подобных) выходные данные уже переданы в задействованное аппаратное обеспечение вместе со всеми метаданными файла, которые бы потребовались для получения данных (т. е., как если бы за каждым \fBwrite\fP(2) был выполнен вызов \fBfdatasync\fP(2)). \fIСмотрите ЗАМЕЧАНИЯ далее\fP. .TP \fBO_EXCL\fP Гарантирует, что вызов создаст файл: если этот флаг указан вместе с \fBO_CREAT\fP и \fIpathname\fP уже существует, то \fBopen\fP() завершается ошибкой \fBEEXIST\fP(). .IP .\" POSIX.1-2001 explicitly requires this behavior. При использовании обоих флагов символьные ссылки не поддерживаются: если \fIpathname\fP является символьной ссылкой, то \fBopen\fP() завершается с ошибкой независимо от того, куда указывает ссылка. .IP Вообще говоря, поведение с \fBO_EXCL\fP не определено, если этот флаг используется без \fBO_CREAT\fP. Есть одно исключение: в Linux 2.6 и более новых \fBO_EXCL\fP можно использовать без \fBO_CREAT\fP, если \fIpathname\fP указывает на блочное устройство. Если блочное устройство используется в системе (например, смонтировано), то \fBopen\fP() завершится с ошибкой \fBEBUSY\fP. .IP Флаг \fBO_EXCL\fP поддерживается для NFS только, если используется NFSv3 или новее с ядром 2.6 или новее. В средах, где в NFS нет поддержки \fBO_EXCL\fP, программы, которые полагаются на это для выполнения задач блокировок, будут создавать состязательность процессов. Переносимым программам, которым нужно произвести атомарную блокировку файла с помощь файла блокировки, необходимо избегать зависимости от поддержки в NFS флага \fBO_EXCL\fP. В качестве решения можно создать уникальный файл в той же файловой системе (например, добавив имя узла и PID в название), чтобы создать ссылку на файл блокировки с помощью \fBlink\fP(2). Если \fBlink\fP(2) возвращает 0, то блокировка выполнена. В противном случае используйте \fBstat\fP(2), чтобы убедиться, что количество ссылок на уникальный файл возросло до двух. Это также означает, что блокировка была успешной. .TP \fBO_LARGEFILE\fP (LFS) Позволяет открывать файлы, чей размер нельзя представить типом \fIoff_t\fP (но можно представить типом \fIoff64_t\fP). Для получения этого определения должен быть указан макрос \fB_LARGEFILE64_SOURCE\fP (до включения \fIкакого\-либо\fP заголовочного файла). Установка макроса тестирования возможностей \fB_FILE_OFFSET_BITS\fP в значение 64 (вместо использования \fBO_LARGEFILE\fP) является предпочтительным методом доступа к большим файлам на 32\-битных системах (см. \fBfeature_test_macros\fP(7)). .TP \fBO_NOATIME\fP (начиная с Linux 2.6.8) Не обновлять время последнего доступа к файлу (\fIst_atime\fP в иноде) при вызове \fBread\fP(2) для файла. .IP Этот флаг может использоваться только, если удовлетворяется одно из следующих условий: .RS .IP * 3 .\" Strictly speaking: the filesystem UID Эффективный пользовательский идентификатор процесса совпадает идентификатором владельца файла. .IP * Вызывающий процесс имеет мандат \fBCAP_FOWNER\fP в своём пользовательском пространстве имён и UID владельца файла отображён в пространстве имён. .RE .IP .\" The O_NOATIME flag also affects the treatment of st_atime .\" by mmap() and readdir(2), MTK, Dec 04. Этот флаг предназначен для использования в программах индексирования и резервного копирования; он позволяет значительно сократить количество обращений к диску. Флаг может быть не эффективен на некоторых файловых системах. Например, на NFS, где запись времени доступа выполняется сервером. .TP \fBO_NOCTTY\fP Если \fIpathname\fP указывает на терминальное устройство (см. \fBtty\fP(4)), то оно не станет управляющим терминалом процесса, даже если процесс такового не имеет. .TP \fBO_NOFOLLOW\fP If the trailing component (i.e., basename) of \fIpathname\fP is a symbolic link, then the open fails, with the error \fBELOOP\fP. Symbolic links in earlier components of the pathname will still be followed. (Note that the \fBELOOP\fP 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.) .IP Данный флаг является расширением FreeBSD, которое было добавлено в Linux версии 2.1.126, и в последствии был стандартизован в POSIX.1\-2008. .IP .\" The headers from glibc 2.0.100 and later include a .\" definition of this flag; \fIkernels before 2.1.126 will ignore it if .\" used\fP. Смотрите также далее \fBO_PATH\fP. .TP \fBO_NONBLOCK\fP или \fBO_NDELAY\fP Если возможно, файл открывается в неблокирующем режиме. Ни \fBopen\fP(), ни другие последующие операции ввода\-вывода над возвращаемым дескриптором файла не заставят вызывающий процесс ждать. .IP Заметим, что установка этого флага не влияет на операции \fBpoll\fP(2), \fBselect\fP(2), \fBepoll\fP(7) и подобные, так как их интерфейсы просто информируют вызывающего о том, что файловый дескриптор «ready», то есть операция ввода\-вывода, выполняемая над файловым дескриптором с флагом \fBO_NONBLOCK\fP, \fIточно\fP не заблокируется. .IP Обратите внимание, что этот флаг не оказывает влияния на обычные файлы и блочные устройства, то есть операции ввода\-вывода будут блокироваться на короткое время, если будет запрошено активность устройства, вне зависимости от установки флага \fBO_NONBLOCK\fP. Семантика \fBO_NONBLOCK\fP может быть когда\-нибудь реализована, поэтому приложения не должны зависеть от блокировок при указании данного флага для обычных файлов и блочных устройств. .IP Для работы с каналами FIFO также смотрите \fBfifo\fP(7). Обсуждение влияния \fBO_NONBLOCK\fP в сочетании с обязательной файловой блокировкой или арендой (lease) смотрите в \fBfcntl\fP(2). .TP \fBO_PATH\fP (начиная с Linux 2.6.39) .\" commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bd .\" commit 326be7b484843988afe57566b627fb7a70beac56 .\" commit 65cfc6722361570bfe255698d9cd4dccaf47570d .\" .\" http://thread.gmane.org/gmane.linux.man/2790/focus=3496 .\" Subject: Re: [PATCH] open(2): document O_PATH .\" Newsgroups: gmane.linux.man, gmane.linux.kernel .\" Получить файловый дескриптор, который можно использовать для двух целей: для указания положения в дереве файловой системы и для выполнения операций, работающих исключительно на уровне файловых дескрипторов. Сам файл не открывается и другие файловые операции (например, \fBread\fP(2), \fBwrite\fP(2), \fBfchmod\fP(2), \fBfchown\fP(2), \fBfgetxattr\fP(2), \fBioctl\fP(2), \fBmmap\fP(2)) завершатся с ошибкой \fBEBADF\fP. .IP Следующие операции \fIмогут\fP выполняться над полученным файловым дескриптором: .RS .IP * 3 \fBclose\fP(2). .IP * .\" commit 332a2e1244bd08b9e3ecd378028513396a004a24 \fBfchdir\fP(2), если файловый дескриптор указывает на каталог (начиная с Linux 3.5). .IP * \fBfstat\fP(2) (начиная с Linux 3.6). .IP * .\" fstat(): commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 .\" fstatfs(): commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf \fBfstatfs\fP(2) (начиная с Linux 3.12). .IP * Создание дубликата файлового дескриптора (\fBdup\fP(2), \fBfcntl\fP(2) \fBF_DUPFD\fP и т.д.). .IP * Получение и установка флагов файловых дескрипторов (\fBfcntl\fP(2) \fBF_GETFD\fP и \fBF_SETFD\fP). .IP * Получение флагов состояния открытого файла с помощью операции \fBfcntl\fP(2) \fBF_GETFL\fP: в возвращаемые флаги будет включён бит \fBO_PATH\fP. .IP * Передача файлового дескриптора в аргументе \fIdirfd\fP для \fBopenat\fP() и других системных вызовов «*at()». К ним относится \fBlinkat\fP(2) с флагом \fBAT_EMPTY_PATH\fP (или через procfs с помощью \fBAT_SYMLINK_FOLLOW\fP) даже, если файл не является каталогом. .IP * Передача файлового дескриптора в другой процесс через доменный сокет UNIX (смотрите \fBSCM_RIGHTS\fP в \fBunix\fP(7)). .RE .IP Если в \fIflags\fP указан \fBO_PATH\fP, то биты флагов, отличные от \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fPи \fBO_NOFOLLOW\fP, игнорируются. .IP Открытие файла или каталога при указании флага \fBO_PATH\fP не требует прав на сам объект (но требует права на выполнение каталогов из префикса пути). В зависимости от последующей операции может выполняться проверка определённых прав на файл (например, \fBfchdir\fP(2) требует права на выполнение у каталога, указанного в аргументе файлового дескриптора). Напротив, для получения ссылки на объект файловой системы при открытии с флагом \fBO_RDONLY\fP от вызывающего требуется право на чтение объекта, даже если для последующей операции (например, \fBfchdir\fP(2), \fBfstat\fP(2)) не требуется права чтения объекта. .IP Если \fIpathname\fP является символьной ссылкой и также указан флаг \fBO_NOFOLLOW\fP, то вызов возвращает файловый дескриптор, указывающий на символьную ссылку. Этот файловый дескриптор можно использовать в аргументе \fIdirfd\fP для вызовов \fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2) и \fBreadlinkat\fP(2) с пустым именем пути, чтобы выполнить операцию над символьной ссылкой. .IP Если \fIpathname\fP ссылается на автоматическую точку монтирования, которая ещё не включилась, и поэтому к ней не примонтированы другие файловые системы, то вызов возвращает файловый дескриптор, указывающий на каталог автомонтирования, не вызывая запуск монтирования. Затем можно использовать вызов \fBfstatfs\fP(2) для определения, является ли автоматическая точка монтирования включённой (\fB.f_type == AUTOFS_SUPER_MAGIC\fP). .IP Одним из вариантов использования флага \fBO_PATH\fP для обычных файлов — предоставление эквивалента функции \fBO_EXEC\fP, описанной POSIX.1. Вызывающий может открыть файл, для которого имеется право на выполнение, но не права на чтение, и затем выполнить этот файл следующими действиями: .IP .in +4n .EX 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); .EE .in .IP Файловый дескриптор с \fBO_PATH\fP также может быть передан в качестве аргумента \fBfexecve\fP(3). .TP \fBO_SYNC\fP Операции записи файла будут выполнены согласно требованиям целостности синхронизации ввода\-вывода \fIfile\fP (по сравнению с целостностью синхронизации ввода\-вывода \fIdata\fP, предоставляемой \fBO_DSYNC\fP). .IP На момент возврата из \fBwrite\fP(2) (или подобной функции) выходные данные и все метаданные файла уже переданы в задействованное аппаратное обеспечение (т. е., как если бы за каждым \fBwrite\fP(2) был выполнен вызов \fBfsync\fP(2)). \fIСмотрите ЗАМЕЧАНИЯ далее\fP. .TP \fBO_TMPFILE\fP (начиная с Linux 3.11) .\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e .\" commit f4e0c30c191f87851c4a53454abb55ee276f4a7e .\" commit bb458c644a59dbba3a1fe59b27106c5e68e1c4bd Создание безымянного временного обычного файла. В аргументе \fIpathname\fP указывается каталог; безымянная inode будет создана в файловой системе этого каталога. Всё записанное в полученный файл будет потеряно при закрытии последнего файлового дескриптора, если файлу не будет назначено имя. .IP Флаг \fBO_TMPFILE\fP должен быть указан вместе с \fBO_RDWR\fP или \fBO_WRONLY\fP и, необязательно, \fBO_EXCL\fP. Если \fBO_EXCL\fP не указан, то можно использовать \fBlinkat\fP(2) для ссылки на временный файл в файловой системе, сделав его постоянным с помощью кода: .IP .in +4n .EX char path[PATH_MAX]; fd = open("/path/to/dir", O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR); /* File I/O on \(aqfd\(aq... */ linkat(fd, NULL, AT_FDCWD, "/path/for/file", AT_EMPTY_PATH); /* If the caller doesn\(aqt 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); */ .EE .in .IP В этом случае аргументом \fImode\fP у \fBopen\fP() определяется режим доступа к файлу как с \fBO_CREAT\fP. .IP Указание \fBO_EXCL\fP вместе с \fBO_TMPFILE\fP отключает возможность создания символьной ссылки в файловой системе указанным ранее способом (заметим, что назначение \fBO_EXCL\fP в этом случае отличается от обычного \fBO_EXCL\fP). .IP .\" Inspired by http://lwn.net/Articles/559147/ Есть два основных случая использования \fBO_TMPFILE\fP: .RS .IP * 3 Дополнительное свойство \fBtmpfile\fP(3): свободное от состязательности создание временных файлов, которые: автоматически удаляются при закрытии; недоступны по имени; не подвержены атаке через символьные ссылки; не требуют от вызывающего подбирать уникальное имя. .IP * Создание файла, который изначально не видим, и который затем заполняется данными и позволяет изменять атрибуты в файловой системе (\fBfchown\fP(2), \fBfchmod\fP(2), \fBfsetxattr\fP(2) и т. д.) до автоматического встраивания в файловую систему в полностью законченном виде (с помощью \fBlinkat\fP(2) как описано ранее). .RE .IP .\" To check for support, grep for "tmpfile" in kernel sources .\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788 .\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe .\" commit ef3b9af50bfa6a1f02cd7b3f5124b712b1ba3e3c .\" commit 50732df02eefb39ab414ef655979c2c9b64ad21c Для \fBO_TMPFILE\fP требуется поддержка в файловой системе; она есть только в нескольких файловых системах Linux. В первой реализации поддержка предоставлялась в файловых системах ext2, ext3, ext4, UDF, Minix и shmem. Поддержка других файловых систем появлялась так: XFS (Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); ubifs (Linux 4.9). .TP \fBO_TRUNC\fP Если файл уже существует и является обычным файлом и режим доступа позволяет писать в этот файл (т.е. установлен флаг \fBO_RDWR\fP или \fBO_WRONLY\fP), то его длина будет урезана до нуля. Если файл является FIFO или терминальным устройством, то этот флаг игнорируется. В других случаях действие флага \fBO_TRUNC\fP не определено. .SS creat() Вызов \fBcreat\fP() эквивалентен вызову \fBopen\fP() с значением \fIflags\fP \fBO_CREAT|O_WRONLY|O_TRUNC\fP. .SS openat() Системный вызов \fBopenat\fP() работает также как системный вызов \fBopen\fP(), за исключением случаев, описанных здесь. .PP Если в \fIpathname\fP задан относительный путь, то он считается относительно каталога, на который ссылается файловый дескриптор \fIdirfd\fP (а не относительно текущего рабочего каталога вызывающего процесса, как это делается в \fBopen\fP()). .PP Если в \fIpathname\fP задан относительный путь и \fIdirfd\fP равно специальному значению \fBAT_FDCWD\fP, то \fIpathname\fP рассматривается относительно текущего рабочего каталога вызывающего процесса (как \fBopen\fP()). .PP .\" Если в \fIpathname\fP задан абсолютный путь, то \fIdirfd\fP игнорируется. .SS openat2(2) The \fBopenat2\fP(2) system call is an extension of \fBopenat\fP(), and provides a superset of the features of \fBopenat\fP(). It is documented separately, in \fBopenat2\fP(2). .SH "ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ" \fBopen\fP(), \fBopenat\fP(), and \fBcreat\fP() return the new file descriptor (a nonnegative integer), or \-1 if an error occurred (in which case, \fIerrno\fP is set appropriately). .SH ОШИБКИ Вызовы \fBopen\fP(), \fBopenat\fP() и \fBcreat\fP() могут завершаться со следующими ошибками: .TP \fBEACCES\fP Запрошенный доступ к файлу не разрешён, или один из каталогов в \fIpathname\fP не позволяет поиск, файл ещё не существует, или доступ для записи в родительский каталог не разрешён (см. также \fBpath_resolution\fP(7)). .TP \fBEACCES\fP .\" commit 30aba6656f61ed44cba445a3c0d38b296fa9e8f5 Where \fBO_CREAT\fP is specified, the \fIprotected_fifos\fP or \fIprotected_regular\fP 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 \fI/proc/sys/fs/protected_fifos\fP and \fI/proc/sys/fs/protected_regular\fP in \fBproc\fP(5). .TP \fBEBUSY\fP \fBO_EXCL\fP was specified in \fIflags\fP and \fIpathname\fP refers to a block device that is in use by the system (e.g., it is mounted). .TP \fBEDQUOT\fP Если указан флаг \fBO_CREAT\fP, файл не существует и исчерпана пользовательская квота на дисковые блоки или inode файловой системы. .TP \fBEEXIST\fP \fIpathname\fP уже существует, то были указаны \fBO_CREAT\fP и \fBO_EXCL\fP. .TP \fBEFAULT\fP Аргумент \fIpathname\fP указывает за пределы доступного адресного пространства. .TP \fBEFBIG\fP Смотрите \fBEOVERFLOW\fP. .TP \fBEINTR\fP При блокирующем ожидании завершения открытия медленного устройства (например, FIFO; см. \fBfifo\fP(7)), вызов был прерван обработчиком сигнала; смотрите \fBsignal\fP(7). .TP \fBEINVAL\fP Файловая система не поддерживает флаг \fBO_DIRECT\fP. Подробности смотрите в \fBЗАМЕЧАНИЯ\fP. .TP \fBEINVAL\fP .\" In particular, __O_TMPFILE instead of O_TMPFILE Некорректное значение \fIflags\fP. .TP \fBEINVAL\fP В \fIflags\fP указан \fBO_TMPFILE\fP, но не указан \fBO_WRONLY\fP или \fBO_RDWR\fP. .TP \fBEINVAL\fP В \fIflags\fP указан \fBO_CREAT\fP и последний компонент («основная часть» (basename)) нового файла \fIpathname\fP некорректен (например, содержит недопустимые в нижележащей файловой системе символы). .TP \fBEINVAL\fP The final component ("basename") of \fIpathname\fP is invalid (e.g., it contains characters not permitted by the underlying filesystem). .TP \fBEISDIR\fP \fIpathname\fP указывает на каталог и тип доступа подразумевает запись ( то есть установлен флаг \fBO_WRONLY\fP или \fBO_RDWR\fP). .TP \fBEISDIR\fP Значение \fIpathname\fP ссылается на существующий каталог, в \fIflags\fP указан \fBO_TMPFILE\fP и один из \fBO_WRONLY\fP или \fBO_RDWR\fP, но версия ядра не предоставляет свойство \fBO_TMPFILE\fP. .TP \fBELOOP\fP Во время определения \fIpathname\fP встретилось слишком много символьных ссылок. .TP \fBELOOP\fP Значение \fIpathname\fP является символьной ссылкой и в \fIflags\fP установлен \fBO_NOFOLLOW\fP, но отсутствует \fBO_PATH\fP. .TP \fBEMFILE\fP Было достигнуто ограничение по количеству открытых файловых дескрипторов на процесс (смотрите описание \fBRLIMIT_NOFILE\fP в \fBgetrlimit\fP(2)). .TP \fBENAMETOOLONG\fP \fIpathname\fP слишком длинен. .TP \fBENFILE\fP Достигнуто максимальное количество открытых файлов в системе. .TP \fBENODEV\fP \fIpathname\fP ссылается на специальный файл устройства, но соответствующего устройства не существует (это ошибка в ядре Linux: должно возвращаться \fBENXIO\fP). .TP \fBENOENT\fP Не задан \fBO_CREAT\fP и файл с указанным именем не существует. .TP \fBENOENT\fP Один из каталогов в \fIpathname\fP не существует или является повисшей символьной ссылкой. .TP \fBENOENT\fP Значение \fIpathname\fP ссылается на несуществующий каталог, в \fIflags\fP указан \fBO_TMPFILE\fP и один из \fBO_WRONLY\fP или \fBO_RDWR\fP, но версия ядра не предоставляет свойство \fBO_TMPFILE\fP. .TP \fBENOMEM\fP Типом файла с именем является FIFO, но память для буфера FIFO невозможно выделить, так как достигнуто жёсткое пользовательское ограничение на выделение памяти для каналов и вызывающий не имеет дополнительных прав; смотрите \fBpipe\fP(7). .TP \fBENOMEM\fP Недостаточное количество памяти ядра. .TP \fBENOSPC\fP Файл \fIpathname\fP должен быть создан, но на устройстве его содержащем нет места для нового файла. .TP \fBENOTDIR\fP Компонент, который обозначен как каталог в \fIpathname\fP, таковым не является, или был указан флаг \fBO_DIRECTORY\fP, но \fIpathname\fP не является каталогом. .TP \fBENXIO\fP Установлены \fBO_NONBLOCK\fP | \fBO_WRONLY\fP , именованный файл имеет тип FIFO и ни один процесс не открыл FIFO на чтение. .TP \fBENXIO\fP Файл является специальным файлом устройства, но соответствующее устройство не существует. .TP \fBENXIO\fP Файл является доменным сокетом UNIX. .TP \fBEOPNOTSUPP\fP Файловая система, содержащая \fIpathname\fP, не поддерживает \fBO_TMPFILE\fP. .TP \fBEOVERFLOW\fP .\" See http://bugzilla.kernel.org/show_bug.cgi?id=7253 .\" "Open of a large file on 32-bit fails with EFBIG, should be EOVERFLOW" .\" Reported 2006-10-03 \fIpathname\fP ссылается на обычный файл, который слишком велик для открытия. Обычно, это случается когда приложение, скомпилированное на 31\-битной платформе без \fI\-D_FILE_OFFSET_BITS=64\fP, пытается открыть файл размером более \fI(1<<31)\-1\fP байт; смотрите также описание \fBO_LARGEFILE\fP ранее. Эта ошибка определена в POSIX.1; в ядрах до версии 2.6.24 Linux в этом случае выдавал ошибку \fBEFBIG\fP. .TP \fBEPERM\fP .\" Strictly speaking, it's the filesystem UID... (MTK) Задан флаг \fBO_NOATIME\fP, но эффективный ID пользователя вызывающего процесса не совпадает с владельцем файла и вызывающий не имеет прав. .TP \fBEPERM\fP Выполнение операции предотвращено опечатыванием (file seal); смотрите \fBfcntl\fP(2). .TP \fBEROFS\fP \fIpathname\fP указывает на файл на файловой системе, доступной только на чтение, но запрашивается доступ на запись. .TP \fBETXTBSY\fP \fIpathname\fP указывает на исполняемый файл, который запущен в данный момент, но запрашивается доступ на запись. .TP \fBETXTBSY\fP \fIpathname\fP указывает на файл, который в данный момент используется как файл подкачки и был указан флаг \fBO_TRUNC\fP. .TP \fBETXTBSY\fP \fIpathname\fP указывает на файл, который в данный момент читается ядром (например, для загрузки модуля/микропрограммы) и запрашивается доступ на запись. .TP \fBEWOULDBLOCK\fP Указан флаг \fBO_NONBLOCK\fP, но несовместимая аренда (lease) удерживает файл (смотрите \fBfcntl\fP(2)). .PP В \fBopenat\fP() дополнительно могут возникнуть следующие ошибки: .TP \fBEBADF\fP \fIdirfd\fP не является правильным файловым дескриптором. .TP \fBENOTDIR\fP Значение \fIpathname\fP содержит относительный путь и \fIdirfd\fP содержит файловый дескриптор, указывающий на файл, а не на каталог. .SH ВЕРСИИ Вызов \fBopenat\fP() был добавлен в ядро Linux версии 2.6.16; поддержка в glibc доступна с версии 2.4. .SH "СООТВЕТСТВИЕ СТАНДАРТАМ" \fBopen\fP(), \fBcreat\fP() SVr4, 4.3BSD, POSIX.1\-2001, POSIX.1\-2008. .PP \fBopenat\fP(): POSIX.1\-2008. .PP \fBopenat2\fP(2) is Linux\-specific. .PP Флаги \fBO_DIRECT\fP, \fBO_NOATIME\fP, \fBO_PATH\fP и \fBO_TMPFILE\fP есть только в Linux. Для их определения может потребоваться задать \fB_GNU_SOURCE\fP. .PP Флаги \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP и \fBO_NOFOLLOW\fP не указаны в POSIX.1\-2001, но есть в POSIX.1\-2008. Начиная с glibc 2.12, их определения можно получить определив или \fB_POSIX_C_SOURCE\fP со значением большим и равным 200809L, или \fB_XOPEN_SOURCE\fP со значением большим и равным 700. В glibc 2.11 и старее их определения можно получить определив \fB_GNU_SOURCE\fP. .PP Как было отмечено в \fBfeature_test_macros\fP(7), такие макросы тестирования свойств как \fB_POSIX_C_SOURCE\fP, \fB_XOPEN_SOURCE\fP и \fB_GNU_SOURCE\fP, должны быть определены до включения \fIлюбых\fP заголовочных файлов. .SH ЗАМЕЧАНИЯ В Linux флаг \fBO_NONBLOCK\fP иногда используется в случаях, когда файл только открыть, и не обязательно будет производиться чтение или запись. Например, он может использоваться для открытия устройства, чтобы получить его файловый дескриптор для использования в \fBioctl\fP(2). .PP .\" Linux 2.0, 2.5: truncate .\" Solaris 5.7, 5.8: truncate .\" Irix 6.5: truncate .\" Tru64 5.1B: truncate .\" HP-UX 11.22: truncate .\" FreeBSD 4.7: truncate Результат работы комбинации флагов \fBO_RDONLY | O_TRUNC\fP в разных реализациях разный (нигде не определён). Во многих системах файл усекается. .PP Заметим, что \fBopen\fP() может открывать специальные файлы устройств, но \fBcreat\fP() не может их создавать; вместо этого используйте \fBmknod\fP(2). .PP Если файл только что был создан, его поля \fIst_atime\fP, \fIst_ctime\fP, \fIst_mtime\fP (время последнего доступа, последней смены состояния и последнего изменения, соответственно; см. \fBstat\fP(2)) устанавливаются в значение текущего времени, и оно совпадает с полями \fIst_ctime\fP и \fIst_mtime\fP родительского каталога. Или же, если файл изменяется из\-за установленного флага \fBO_TRUNC\fP, то его поля \fIst_ctime\fP и \fIst_mtime\fP устанавливаются в значение текущего времени. .PP Файлы в каталоге \fI/proc/[pid]/fd\fP представляют открытые файловые дескрипторы процесса с PID равным \fIpid\fP. Файлы в каталоге \fI/proc/[pid]/fdinfo\fP представляют дополнительную информацию об этих файловых дескрипторах. Подробное описание данных каталогов можно найти в \fBproc\fP(5). .PP .\" .\" В заголовочном файле Linux \fB\fP не определён \fBO_ASYNC\fP; вместо него определён синоним \fBFASYNC\fP (как в BSD). .SS "Открытые файловые описания" Термин «открытое файловое описание» (open file description) используется в POSIX для указания на записи в системной таблице открытых файлов. В других контекстах, этот объект также называется «открытый файловый объект» (open file object), «описатель файла» (file handle), «»табличная запись открытого файла (open file table entry) или \fIstruct file\fP (с точки зрения разработчика ядра). .PP При создании копии файлового дескриптора (с помощью \fBdup\fP(2) или подобного вызова), копия ссылается на то же открытое файловое описание что и изначальный файловый дескриптор, и, следовательно, два файловых дескриптора имеют общее файловое смещение и флаги состояния файла. Такая общность может также быть у двух процессов: процесс\-потомок, создаваемый \fBfork\fP(2), наследует копии файловых дескрипторов своего родителя и эти копии ссылаются на те же открытые файловые описания. .PP При каждом \fBopen\fP() файла создаётся новое файловое описание; таким образом, может быть несколько открытых файловых описаний, соответствующих inode файла. .PP .\" .\" Для проверки того, что два файловых дескриптора (одного процесса или разных) ссылаются на одно файловое описание, в Linux можно использовать вызов \fBkcmp\fP(2) с операцией \fBKCMP_FILE\fP. .SS "Синхронизированный ввод\-вывод" В POSIX.1\-2008 способность «синхронизированного ввода\-вывода» описана в виде различных вариантов синхронизированного ввода\-вывода и для \fBopen\fP() определяет флаги управления поведением \fBO_SYNC\fP, \fBO_DSYNC\fP и \fBO_RSYNC\fP. Независимо от того, имеется ли в реализации данная способность, она должна, как минимум, поддерживать использование флага \fBO_SYNC\fP для обычных файлов. .PP В Linux реализованы \fBO_RSYNC\fP и \fBO_DSYNC\fP, но не \fBO_RSYNC\fP. Несколько некорректно в glibc определён \fBO_RSYNC\fP со значением как у \fBO_SYNC\fP (\fBO_RSYNC\fP определён в заголовочном файле Linux \fI\fP для HP PA\-RISC, но не используется). .PP Флаг \fBO_SYNC\fP предоставляет выполнение целостного синхронизованного ввод\-вывода \fIfile\fP, то есть операции записи передают данные и все связанные метаданные в задействованное аппаратное обеспечение. Флаг \fBO_DSYNC\fP предоставляет выполнение целостного синхронизованного ввод\-вывода \fIdata\fP, то есть операции записи передают данные в задействованное аппаратное обеспечение, но обновляются только те метаданные, которые требуются для выполнения последующего чтения. Полнота целостности данных может сократить количество дисковых операций, которые требуются приложениям, не требующим гарантий целостности файлов. .PP Чтобы понять разницу между двумя типами обеспечения целостности рассмотрим две части метаданных файла: метка времени последнего изменения файла (\fIst_mtime\fP) и длину файла. Все операции записи обновляют метку времени последнего изменения файла, но только при записи, которая добавляет данные в конец файла, будет изменена длина файла. Метка времени последнего изменения файла не требуется для корректного чтения файла, чего не скажешь о длине. Таким образом, \fBO_DSYNC\fP гарантирует только запись обновлений о метаданных длины файла (в то время как \fBO_SYNC\fP также всегда записывает метаданные о метки времени последнего изменения файла). .PP До Linux версии 2.6.33 в Linux реализован только флаг \fBO_SYNC\fP для \fBopen\fP(). Однако, когда этот флаг указан, большинство файловых систем в действительности предоставляют эквивалент выполнения целостности синхронизированного ввода\-вывода \fIdata\fP (т. е., на самом деле \fBO_SYNC\fP был реализован как эквивалент \fBO_DSYNC\fP). .PP .\" Начиная с Linux 2.6.33, предоставляет корректная поддержка \fBO_SYNC\fP. Однако для обеспечения обратной двоичной совместимости, \fBO_DSYNC\fP был определён с тем же значением что и старый \fBO_SYNC\fP, а \fBO_SYNC\fP был определён как новое значение флага (два бита), которое включает значение флага \fBO_DSYNC\fP. Это позволяет приложениям, скомпилированным с новыми заголовочными файлами получать, по крайней мере, семантику \fBO_DSYNC\fP ядер pre\-2.6.33. .SS "Отличия между библиотекой C и ядром" .\" Начиная с версии 2.26, обёрточная функция glibc \fBopen\fP() используется системный вызов \fBopenat\fP(), а не системный вызов ядра \fBopen\fP(). На некоторых архитектурах это происходит в glibc с версиями ранее 2.26. .SS NFS В протоколе, по которому работает NFS, существует множество недоработок, оказывающих влияние на многое, в том числе на работу с \fBO_SYNC\fP и \fBO_NDELAY\fP. .PP .\" .\" В файловых системах NFS с включённым проецированием UID, \fBopen\fP() может вернуть файловый дескриптор, но, например, запросы \fBread\fP(2) будут отклонены с ошибкой \fBEACCES\fP. Это происходит из\-за того, что клиент выполняет \fBopen\fP() проверяя одни права, но сервер выполняет проецирование UID только при запросах чтения и записи. .SS FIFO .\" .\" Открытие на чтение или запись конца FIFO приводит к блокировке то тех пор, пока другой конец не также не будет открыт (другим процессом или нитью). Подробности смотрите в \fBfifo\fP(7). .SS "Режим доступа к файлу" В отличие от других значений, указываемых в \fIflags\fP, значения \fIрежима доступа\fP \fBO_RDONLY\fP, \fBO_WRONLY\fP и \fBO_RDWR\fP, не определяются отдельными битами. Точнее, они задаются двумя первыми битами \fIflags\fP, и имеют значения 0, 1 и 2, соответственно. Другими словами, комбинация \fBO_RDONLY | O_WRONLY\fP приводит к логической ошибке и точно не работает как \fBO_RDWR\fP. .PP .\" See for example util-linux's disk-utils/setfdprm.c .\" For some background on access mode 3, see .\" http://thread.gmane.org/gmane.linux.kernel/653123 .\" "[RFC] correct flags to f_mode conversion in __dentry_open" .\" LKML, 12 Mar 2008 .\" .\" В Linux зарезервирован специальный нестандартный режим доступа 3 (11 двоичное) в \fIflags\fP, при котором: проверяются права на чтение и запись к файлу и возвращается файловый дескриптор, который не может использоваться для чтения или записи. Данный нестандартный режим доступа используется некоторыми драйверами Linux для получения файлового дескриптора, который будет использоваться в \fBioctl\fP(2) только для специальных операций с устройством. .SS "Обоснование openat() и остального программного интерфейса файлового дескриптора каталога" \fBopenat\fP() and the other system calls and library functions that take a directory file descriptor argument (i.e., \fBexecveat\fP(2), \fBfaccessat\fP(2), \fBfanotify_mark\fP(2), \fBfchmodat\fP(2), \fBfchownat\fP(2), \fBfspick\fP(2), \fBfstatat\fP(2), \fBfutimesat\fP(2), \fBlinkat\fP(2), \fBmkdirat\fP(2), \fBmove_mount\fP(2), \fBmknodat\fP(2), \fBname_to_handle_at\fP(2), \fBopen_tree\fP(2), \fBopenat2\fP(2), \fBreadlinkat\fP(2), \fBrenameat\fP(2), \fBstatx\fP(2), \fBsymlinkat\fP(2), \fBunlinkat\fP(2), \fButimensat\fP(2), \fBmkfifoat\fP(3), and \fBscandirat\fP(3)) address two problems with the older interfaces that preceded them. Here, the explanation is in terms of the \fBopenat\fP() call, but the rationale is analogous for the other interfaces. .PP Во\-первых, \fBopenat\fP() позволяет приложению избежать условий состязательности, которые могут возникнуть, когда \fBopen\fP() открывает файлы в каталогах, отличных от текущего рабочего каталога. Состязательность возникает из\-за того, что один из компонентов префикса каталога, указанного \fBopen\fP(), может измениться одновременно с вызовом \fBopen\fP(). Например, предположим, что мы хотим создать файл \fIdir1/dir2/xxx.dep\fP и существует файл \fIdir1/dir2/xxx\fP. Проблема находится между шагами проверки существования и созданием файла, указываемые \fIdir1\fP или \fIdir2\fP (которые могут быть символическими ссылками) места могут измениться. Этой состязательности можно избежать открыв файловый дескриптор каталога назначения, и затем указав этот файловый дескриптор в аргументе \fIdirfd\fP вызова (скажем) \fBfstatat\fP(2) и \fBopenat\fP(). Также, использование файлового дескриптора \fIdirfd\fP имеет другие преимущества: .IP * 3 файловый дескриптор — это стабильная ссылка на каталог, даже если каталог будет переименован; и .IP * открытый файловый дескриптор предотвращает размонтирование нижележащей файловой системы также, как если бы каталог являлся текущим рабочим каталогом процесса в файловой системе. .PP Во\-вторых, \fBopenat\fP() позволяет реализовать отдельный «текущий рабочий каталог» для каждой нити посредством файлового дескриптора, сопровождаемого приложением. Эта возможность также может быть получена с использованием \fI/proc/self/fd/\fPdirfd, но менее эффективно. .PP The \fIdirfd\fP argument for these APIs can be obtained by using \fBopen\fP() or \fBopenat\fP() to open a directory (with either the \fBO_RDONLY\fP or the \fBO_PATH\fP flag). Alternatively, such a file descriptor can be obtained by applying \fBdirfd\fP(3) to a directory stream created using \fBopendir\fP(3). .PP .\" .\" When these APIs are given a \fIdirfd\fP argument of \fBAT_FDCWD\fP 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 \fIflags\fP argument that provides access to functionality that is not available with the corresponding conventional APIs. .SS O_DIRECT Флаг \fBO_DIRECT\fP может накладывать ограничения по выравниванию на длину и адрес буфера пользовательского пространства и смещения файла при вводе\-выводе. В Linux ограничения по выравниванию различны у разных файловых систем и версий ядра, и даже могут отсутствовать. Однако сейчас не существует независимого от файловой системы интерфейса приложения для выявления этих ограничений на определённый файл или файловую систему. Некоторые файловые системы предоставляют свои собственные интерфейсы для этого, например, операция \fBXFS_IOC_DIOINFO\fP в \fBxfsctl\fP(3). .PP В Linux 2.4 размеры передачи, выравнивание пользовательского буфера и файлового смещения должны быть кратны размеру логического блока файловой системы. Начиная с Linux 2.6 достаточно выравнивания по 512\-байтовой границе. Размер логического блока можно определить с помощью \fBioctl\fP(2) и операции \fBBLKSSZGET\fP или с помощью команды: .PP .in +4n .EX blockdev \-\-getss .EE .in .PP Ввод\-вывод с \fBO_DIRECT\fP никогда не должен запускаться одновременно с системным вызовом \fBfork\fP(2), если буфер памяти является закрытым отображением (т. е., любым отображениям, созданным с помощью \fBmmap\fP(2) с флагом \fBMAP_PRIVATE\fP; к ним относится память, выделенная под кучу и статически выделенные буферы). Любой подобный ввод\-вывод, предоставленный через асинхронный интерфейс или из другой нити процесса, должен выполниться полностью до вызова \fBfork\fP(2). В противном случае, может произойти повреждение данных и непредсказуемое поведение в процессе родителя и потомка.Данное ограничение не действует, если буфер памяти для ввода\-вывода с \fBO_DIRECT\fP был создан с помощью \fBshmat\fP(2) или \fBmmap\fP(2) с флагом \fBMAP_SHARED\fP. И при этом это ограничение не действует, когда буфер памяти был помечен (advised) как \fBMADV_DONTFORK\fP с помощью \fBmadvise\fP(2), если точно известно, что он не будет доступен потомку после \fBfork\fP(2). .PP Флаг \fBO_DIRECT\fP появился в SGI IRIX, где ограничения на выравнивание подобны Linux 2.4. В IRIX также есть вызов \fBfcntl\fP(2) для запроса значений соответствующего выравнивания и размеров. В FreeBSD 4.x появился флаг с таким же именем, но без ограничений на выравнивание. .PP Поддержка \fBO_DIRECT\fP добавлена в ядро Linux версии 2.4.10. Более старые ядра Linux просто игнорируют этот флаг. В некоторых файловых системах этот флаг может быть не реализован и \fBopen\fP() завершается ошибкой \fBEINVAL\fP при его использовании. .PP Приложения должны избегать смешивания \fBO_DIRECT\fP и обычных операций ввода\-вывода в один файл и особенно перекрывать байтовые области. Даже когда файловая система правильно обрабатывает проблемы с когерентностью в такой ситуации, общая пропускная способность ввода\-вывода, вероятно, будет медленнее чем при использовании какого\-то одного из этих режимов отдельно. Аналогично приложения должны избегать смешивания \fBmmap\fP(2) и прямого ввода\-вывода для одинаковых файлов. .PP Поведение \fBO_DIRECT\fP на NFS отличается от локальных файловых систем. Старые ядра и ядра, настроенные определёнными способами, могут не поддерживать такую комбинацию. Протокол NFS не поддерживает передачу флага на сервер, поэтому ввод\-вывод с \fBO_DIRECT\fP будет пропускать кэширование страниц только на клиенте; сервер всё равно может выполнить кэширование ввода\-вывода. Клиент просит сервер выполнять операции ввода\-вывода синхронно для сохранения синхронной семантики \fBO_DIRECT\fP. Некоторые серверы будут выполнять это плохо при определённых условиях, особенно если размер данных ввода\-вывода невелик. Некоторые серверы также могут быть настроены на отправку ложного ответа клиентам о том, что ввод\-вывод произведён на носитель; это позволяет избежать потери производительности, но есть риск потери целостности данных в случае проблем с электропитанием сервера. В Linux клиент NFS не устанавливает ограничений по выравниванию при вводе\-выводе с \fBO_DIRECT\fP. .PP Флаг \fBO_DIRECT\fP является потенциально мощным инструментом, который нужно использовать с осторожностью. Рекомендуется, чтобы приложения считали использование \fBO_DIRECT\fP как параметр производительности, который по умолчанию выключен. .SH ДЕФЕКТЫ .\" FIXME . Check bugzilla report on open(O_ASYNC) .\" See http://bugzilla.kernel.org/show_bug.cgi?id=5993 На данный момент невозможно включить сигнальное управление вводом\-выводом, указав \fBO_ASYNC\fP при вызове \fBopen\fP(); чтобы установить этот флаг используйте \fBfcntl\fP(2). .PP Для определения поддержки ядром \fBO_TMPFILE\fP нужно проверять два различных кода ошибок — \fBEISDIR\fP и \fBENOENT\fP. .PP При указании флагов \fBO_CREAT\fP и \fBO_DIRECTORY\fP в \fIflags\fP, и при этом указанный в \fIpathname\fP файл не существует, \fBopen\fP() создаст обычный файл (то есть флаг \fBO_DIRECTORY\fP будет проигнорирован). .SH "СМ. ТАКЖЕ" \fBchmod\fP(2), \fBchown\fP(2), \fBclose\fP(2), \fBdup\fP(2), \fBfcntl\fP(2), \fBlink\fP(2), \fBlseek\fP(2), \fBmknod\fP(2), \fBmmap\fP(2), \fBmount\fP(2), \fBopen_by_handle_at\fP(2), \fBopenat2\fP(2), \fBread\fP(2), \fBsocket\fP(2), \fBstat\fP(2), \fBumask\fP(2), \fBunlink\fP(2), \fBwrite\fP(2), \fBfopen\fP(3), \fBacl\fP(5), \fBfifo\fP(7), \fBinode\fP(7), \fBpath_resolution\fP(7), \fBsymlink\fP(7) .SH ЗАМЕЧАНИЯ Эта страница является частью проекта Linux \fIman\-pages\fP версии 5.10. Описание проекта, информацию об ошибках и последнюю версию этой страницы можно найти по адресу \%https://www.kernel.org/doc/man\-pages/. .PP .SH ПЕРЕВОД Русский перевод этой страницы руководства был сделан Azamat Hackimov , Konstantin Shvaykovskiy , Yuri Kozlov и Иван Павлов . .PP Этот перевод является бесплатной документацией; прочитайте .UR https://www.gnu.org/licenses/gpl-3.0.html Стандартную общественную лицензию GNU версии 3 .UE или более позднюю, чтобы узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ. .PP Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте электронное письмо на .MT man-pages-ru-talks@lists.sourceforge.net .ME .