open
Section: System Calls (2)
Updated: 5 février 2023
Index
Return to Main Contents
NOM
open, openat, creat - Ouvrir ou créer éventuellement un fichier
BIBLIOTHÈQUE
Bibliothèque C standard (libc, -lc)
SYNOPSIS
#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);
/* Documenté à part, dans openat2(2) : */
int openat2(int dirfd, const char *pathname,
const struct open_how *how, size_t size);
Exigences de macros de test de fonctionnalités pour la glibc (consulter
feature_test_macros(7)) :
openat() :
Depuis la version 2.10 de la glibc :
_POSIX_C_SOURCE >= 200809L
Avant la version 2.10 de la glibc :
_ATFILE_SOURCE
DESCRIPTION
L'appel système open() ouvre le fichier indiqué par pathname. S'il
n'existe pas, il peut (si O_CREAT est indiqué dans flags) être créé
par open().
La valeur renvoyée par open() est un descripteur de fichier, un petit
entier positif ou nul qui est un indice d'entrée dans la table de processus
de descripteurs de fichiers ouverts. Le descripteur de fichier est ensuite
utilisé dans d'autres appels système (read(2), write(2), lseek(2),
fcntl(2), etc.) pour se référer au fichier ouvert. Le descripteur de
fichier renvoyé par un appel réussi sera celui du plus petit numéro de
descripteur de fichier non actuellement ouvert par le processus.
Par défaut, le nouveau descripteur de fichier est configuré pour rester
ouvert après un appel à execve(2) (son attribut FD_CLOEXEC décrit dans
fcntl(2) est initialement désactivé). L'attribut O_CLOEXEC décrit
ci-dessous permet de modifier ce comportement par défaut. La position dans
le fichier est définie au début du fichier (consultez lseek(2)).
Un appel à open() crée une nouvelle description de fichier ouvert, une
entrée dans la table de fichiers ouverts du système. Cette description de
fichier ouvert enregistre la position dans le fichier et les attributs
d’état du fichier (voir ci-dessous). Un descripteur de fichier est une
référence à une description de fichier ouvert ; cette référence n'est pas
modifiée si pathname est ensuite supprimé ou modifié pour faire référence
à un autre fichier. Pour obtenir plus de détails sur les descriptions de
fichiers ouverts, consultez NOTES.
Le paramètre flags est l'un des éléments O_RDONLY, O_WRONLY ou
O_RDWR qui réclament respectivement l'ouverture du fichier en lecture
seule, écriture seule, ou lecture/écriture.
De plus, zéro ou plusieurs attributs de création de fichier et attributs
d'état de fichier peuvent être indiqués dans flags avec un OU
binaire. Les attributs de création de fichier sont O_CLOEXEC,
O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW,
O_TMPFILE et O_TRUNC. Les attributs d'état de fichier sont tous les
autres attributs indiqués ci-dessous. La distinction entre ces deux groupes
est que les attributs d'état de fichier modifient la sémantique de
l'opération d'ouverture elle-même, tandis que les attributs de l'état du
fichier modifient celle des opérations d'E/S qui suivent. Les attributs
d'état de fichier peuvent être lus et (dans certains cas) modifiés ;
consultez fcntl(2) pour plus de précisions.
La liste complète des attributs de création et d'état de fichier est la
suivante.
- O_APPEND
-
Le fichier est ouvert en mode « ajout ». Avant chaque write(2), la tête
de lecture/écriture est placée à la fin du fichier comme avec
lseek(2). La modification de la position dans le fichier et l'opération
d'écriture sont effectuées sous forme d'étape atomique unique.
-
Il y a un risque d'endommager le fichier lorsque O_APPEND est utilisé,
sur un système de fichiers NFS, si plusieurs processus tentent d'ajouter des
données simultanément au même fichier. Ceci est dû au fait que NFS ne gère
pas l'opération d'ajout de données dans un fichier, aussi le noyau du client
est obligé de la simuler, ce qui est impossible sans concurrence des tâches.
- O_ASYNC
-
Déclencher un signal (SIGIO par défaut, mais peut être changé via
fcntl(2)) lorsque la lecture ou l'écriture deviennent possibles sur ce
descripteur. Ceci n'est possible que pour les terminaux, pseudoterminaux,
sockets et (depuis Linux 2.6) tubes et FIFO. Consultez fcntl(2) pour plus
de détails. Consultez aussi BOGUES ci-dessous.
- O_CLOEXEC (depuis Linux 2.6.23)
-
Activer l'attribut « close-on-exec » pour le nouveau descripteur de
fichier. En précisant cet attribut, on évite au programme d'avoir à utiliser
les opérations F_SETFD de fcntl(2) pour positionner l'attribut
FD_CLOEXEC.
-
Notez que le recours à cet attribut est indispensable pour certains
programmes multithreadés. En effet, l'utilisation d'une opération F_SETFD
de fcntl(2) pour positionner l'attribut FD_CLOEXEC ne suffit pas à
éviter une situation d'accès concurrents si un thread ouvre un descripteur
de fichier et tente d'activer l'attribut « close-on-exec » au moyen de
fcntl(2) au moment où un autre thread exécute fork(2) suivi de
execve(2). Selon l'ordre dans lequel ces opérations s'exécutent, cette
concurrence peut aboutir à ce que le descripteur de fichier renvoyé par
open() soit involontairement mis à disposition du programme exécuté par
le processus enfant créé par fork(2). (Ce type de concurrence est en
principe possible pour tout appel système qui crée un descripteur de fichier
dont l'attribut « close-on-exec » est actif ; certains appels système de
Linux offrent des équivalents de l'attribut O_CLOEXEC pour régler ce
problème.)
- O_CREAT
-
Si pathname n'existe pas, le créer en tant que fichier normal.
-
Le propriétaire (identifiant utilisateur) du nouveau fichier est positionné
sur l'identifiant de l'utilisateur effectif du processus.
-
Le groupe (identifiant de groupe) propriétaire du nouveau fichier est soit
positionné sur l'identifiant du groupe effectif du processus (dans la
sémantique de System V), soit sur celui du répertoire parent (dans la
sémantique de BSD). Sur Linux, le comportement varie selon que le
positionnement du bit set-group-ID sur le répertoire parent : s'il est
positionné, la sémantique de BSD s'applique, sinon c'est celle de
System V. Pour certains de fichiers, le comportement dépend aussi des
options de montage bsdgroups et sysvgroups décrites dans mount(8).
-
L'argument mode indique les bits du mode du fichier à appliquer lors de
la création d'un nouveau fichier. Si ni O_CREAT, ni O_TMPFILE ne sont
indiqués dans flags, mode est ignoré (et peut ainsi être indiqué en
tant que 0 voire absent). L'argument mode doit être fourni si
O_CREAT ou O_TMPFILE est indiqué dans flags ; s'il n'est pas
indiqué, des octets arbitraires de la pile s'appliqueront comme mode du
fichier.
-
Le mode effectif est modifié par le umask du processus de manière
classique : en l'absence d'ACL (liste de contrôle d'accès) par défaut, les
droits du fichier créé sont (mode & ~umask).
-
Notez que mode ne s'applique qu'aux accès ultérieurs au fichier
nouvellement créé ; l'appel open() qui crée un fichier dont le mode est
en lecture seule fournira quand même un descripteur de fichier en lecture et
écriture.
-
Les constantes symboliques suivantes sont disponibles pour mode :
-
- S_IRWXU
-
00700 L'utilisateur (propriétaire du fichier) a les autorisations de
lecture, écriture, exécution.
- S_IRUSR
-
00400 L'utilisateur a l'autorisation de lecture.
- S_IWUSR
-
00200 L'utilisateur a l'autorisation d'écriture.
- S_IXUSR
-
00100 L'utilisateur a l'autorisation d'exécution.
- S_IRWXG
-
00070 Le groupe a les autorisations de lecture, écriture, exécution.
- S_IRGRP
-
00040 Le groupe a l'autorisation de lecture.
- S_IWGRP
-
00020 Le groupe a l'autorisation d'écriture.
- S_IXGRP
-
00010 Le groupe a l'autorisation d'exécution.
- S_IRWXO
-
00007 Tout le monde a les autorisations de lecture, écriture, exécution.
- S_IROTH
-
00004 Tout le monde a l'autorisation de lecture.
- S_IWOTH
-
00002 Tout le monde a l'autorisation d'écriture.
- S_IXOTH
-
00001 Tout le monde a l'autorisation d'exécution.
-
Selon POSIX, le positionnement des autres bits dans mode n'a pas d'effet
spécifié. Sur Linux, les bits suivants sont également gérés dans mode :
-
- S_ISUID
-
0004000 bit set-user-ID.
- S_ISGID
-
0002000 bit set-group-ID (voir inode(7)).
- S_ISVTX
-
0001000 bit sticky (voir inode(7)).
- O_DIRECT (depuis Linux 2.4.10)
-
Essayer de minimiser les effets du cache d'entrée-sortie sur ce
fichier. Cela dégradera en général les performances, mais est utile dans des
situations spéciales, comme lorsque les applications ont leur propre
cache. Les entrées-sorties de fichier sont faites directement de et vers les
tampons d'espace utilisateur. L'ajout de l'attribut O_DIRECT fait que les
entrées-sorties sont synchrones ; en réalité un effort est fait pour rendre
le transfert synchrone mais cela n'offre pas la garantie fournie par
l'attribut O_SYNC que les données et métadonnées sont transférées. Pour
garantir des entrées-sorties synchrones, l'attribut O_SYNC doit être
utilisé en plus de l'attribut O_DIRECT. Consultez la section NOTES
ci-dessous.
-
Une interface à la sémantique similaire (mais dépréciée) pour les
périphériques blocs est décrite dans raw(8).
- O_DIRECTORY
-
Si pathname n'est pas un répertoire, l'ouverture échoue. Cet attribut fut
ajouté dans Linux 2.1.126, pour éviter des problèmes de dysfonctionnement si
opendir(3) est invoqué sur une FIFO ou un périphérique à bande.
- O_DSYNC
-
Les opérations d'écriture dans le fichier se dérouleront selon les
conditions d'exécution des opérations E/S synchrones avec garantie
d'intégrité des données.
-
Au moment où write(2) (ou un appel similaire) renvoie une donnée, elle a
été transmise au matériel sur lequel s'exécute l'appel, avec toutes les
métadonnées du fichier qui pourraient être nécessaires à la récupération de
cette donnée (c'est à dire comme si chaque appel à write(2) était suivi
d'un appel à fdatasync(2)). Consultez NOTES ci-dessous.
- O_EXCL
-
S'assurer que cet appel crée le fichier : si cet attribut est spécifié en
conjonction avec O_CREAT et si le fichier pathname existe déjà,
open() échouera avec l'erreur EEXIST.
-
Lorsque ces deux attributs sont spécifiés, les liens symboliques ne sont pas
suivis : si pathname est un lien symbolique, open() échouera quel que
soit l'endroit où pointe le lien symbolique.
-
En général, le comportement de O_EXCL est indéterminé s'il est utilisé
sans O_CREAT. Il existe une exception toutefois : à partir de Linux 2.6,
O_EXCL peut être utilisé sans O_CREAT si pathname fait référence à
un périphérique bloc. Si le périphérique bloc est utilisé par le système
(par exemple, s'il est monté), open() échoue avec l'erreur EBUSY.
-
Sur les systèmes de fichiers NFS, O_EXCL n'est pris en charge qu'avec la
version NFSv3 ou ultérieure, sur les noyaux 2.6 ou plus récents. Dans les
environnements NFS où la prise en charge d'O_EXCL n'est pas fournie, les
programmes qui ont besoin de cette fonctionnalité pour verrouiller des
tâches risquent de rencontrer une concurrence critique (race condition). Les
programmes portables qui veulent effectuer un verrouillage atomique de
fichier en utilisant un fichier verrou et qui doivent éviter la dépendance
de la prise en charge NFS pour O_EXCL peuvent créer un fichier unique sur
le même système de fichiers (par exemple, avec le PID et le nom de l'hôte),
et utiliser link(2) pour créer un lien sur un fichier de verrouillage. Si
link(2) renvoie 0, le verrouillage est réussi. Sinon, utiliser
stat(2) sur ce fichier unique pour vérifier si le nombre de liens a
augmenté jusqu'à 2, auquel cas le verrouillage est également réussi.
- O_LARGEFILE
-
(LFS) Permettre d'ouvrir des fichiers dont la taille ne peut pas être
représentée dans un off_t (mais peut l'être dans un off64_t). La macro
_LARGEFILE64_SOURCE doit être définie (avant d'inclure tout fichier
d'en-tête) pour obtenir cette définition. Définir la macro
_FILE_OFFSET_BITS à 64 est la méthode à favoriser pour accéder à des
grands fichiers sur des systèmes 32 bits, plutôt que d'utiliser
O_LARGEFILE (consultez feature_test_macros(7)).
- O_NOATIME (depuis Linux 2.6.8)
-
Ne pas mettre à jour la date de dernier accès au fichier ((st_atime dans
l'inœud) quand le fichier est read(2).
-
Cet attribut ne peut être utilisé que si l'une des conditions suivantes est
vraie :
-
- •
-
L'identifiant utilisateur effectif du fichier correspond à celui du
propriétaire du fichier.
- •
-
Le processus appelant a la capacité CAP_FOWNER dans son espace de noms
utilisateur et l'identifiant utilisateur du propriétaire du fichier a une
projection dans l'espace de noms.
-
Cet attribut est seulement conçu pour les programmes d'indexation et
d'archivage, pour lesquels il peut réduire significativement l'activité du
disque. L'attribut peut ne pas être effectif sur tous les systèmes de
fichiers. Par exemple, avec NFS, l'heure d'accès est mise à jour par le
serveur.
- O_NOCTTY
-
Si pathname correspond à un périphérique de terminal --- consultez
tty(4) ---, il ne deviendra pas le terminal contrôlant le processus
même si celui-ci n'est attaché à aucun autre terminal.
- O_NOFOLLOW
-
Si le composant final (c'est-à-dire, celui obtenu par basename) de
pathname est un lien symbolique, l'ouverture échoue avec l'erreur
ELOOP. Les liens symboliques dans les composants apparus plus tôt dans le
chemin seront encore suivis (remarquez que l'erreur ELOOP qui peut
intervenir dans ce cas ne peut pas être distinguée de l'échec d'une
ouverture à cause d'un trop grand nombre de liens symboliques lors de la
résolution de composants dans le préfixe du chemin).
-
Cet attribut est une extension FreeBSD qui a été ajoutée dans Linux 2.1.126,
puis normalisée dans POSIX.1-2008.
-
Voir aussi O_PATH ci-dessous.
- O_NONBLOCK ou O_NDELAY
-
Si possible, le fichier est ouvert en mode « non-bloquant ». Ni la
fonction open() ni aucune autre opération d'E/S ultérieure sur le
descripteur de fichier renvoyé ne laissera le processus appelant en attente.
-
Remarquez que positionner cet attribut n'a pas d'effet sur une opération
poll(2), select(2), epoll(7) et équivalentes, puisque ces
interfaces informent simplement l'appelant si un descripteur de fichier est
« ready », à savoir qu'une opération E/S effectuée sur le descripteur de
fichier avec l'attribut O_NONBLOCK clear ne se bloquerait pas.
-
Remarquez que cet attribut n'a aucun effet sur les fichiers ordinaires et
les périphériques de bloc ; c'est-à-dire que les opérations d'E/S se
bloqueront (brièvement) lorsqu’une activité du périphérique est nécessaire,
indépendamment du positionnement de O_NONBLOCK. Comme la sémantique de
O_NONBLOCK pourrait éventuellement être implémentée, les applications ne
doivent pas dépendre d'un blocage comportemental quand elles indiquent cet
attribut pour des fichiers ordinaires et des périphériques de bloc.
-
Pour la manipulation des FIFO (tubes nommés), voir également
fifo(7). Pour une explication de l'effet de O_NONBLOCK en conjonction
avec les verrouillages impératifs et les baux de fichiers, voir fcntl(2).
- O_PATH (depuis Linux 2.6.39)
-
Obtenir un descripteur de fichier qui peut être utile de deux façons : pour
indiquer la localisation dans l'arborescence du système de fichiers et pour
effectuer des opérations exclusivement au niveau du descripteur de
fichier. Le fichier n'est pas lui-même ouvert et d'autres opérations sur le
fichier (par exemple read(2), write(2), fchmod(2), fchown(2),
fgetxattr(2), ioctl(2), mmap(2)) échoueront en renvoyant l'erreur
EBADF.
-
Les opérations suivantes peuvent être réalisées sur le descripteur de
fichier obtenu :
-
- •
-
close(2).
- •
-
fchdir(2), si le descripteur de fichier renvoie à un répertoire (depuis
Linux 3.5).
- •
-
fstat(2) (depuis Linux 3.6)
- •
-
fstatfs(2) (depuis Linux 3.12)
- •
-
Dupliquer le descripteur de fichier (dup(2), fcntl(2), F_DUPFD,
etc.).
- •
-
Consulter et affecter les valeurs des attributs du descripteur de fichier
(fcntl(2), F_GETFD et F_SETFD).
- •
-
Récupérer les attributs d'état de fichiers ouverts au moyen de l'opération
fcntl(2) F_GETFL : les attributs renvoyés comprendront le bit
O_PATH.
- •
-
Transmettre le descripteur de fichier comme l'argument dirfd de
openat(2) et les autres appels système « *at() ». Cela comprend
linkat(2) avec AT_EMPTY_PATH (ou via procfs au moyen de
AT_SYMLINK_FOLLOW) même si le fichier n'est pas un répertoire.
- •
-
Transmettre le descripteur de fichier à un autre processus à l’aide d’un
socket de domaine UNIX (consultez SCM_RIGHTS dans unix(7)).
-
Lorsque O_PATH est précisé dans flags, seuls les bits O_CLOEXEC,
O_DIRECTORY et O_NOFOLLOW de l'attribut sont pris en compte.
-
L'ouverture d'un fichier ou d'un répertoire avec l'attribut O_PATH ne
nécessite pas de droits sur l'objet lui-même (mais elle exige le droit
d'exécution sur les répertoires du préfixe de chemin). En fonction des
opérations ultérieures, la vérification des droits du fichier adéquats peut
se faire (par exemple fchdir(2) exige le droit d'exécution sur le
répertoire auquel renvoie son argument de descripteur de
fichier). Inversement, l'obtention de la référence à un objet de système de
fichiers en l'ouvrant par l'attribut O_RDONLY exige que l'appelant ait le
droit de lire l'objet même quand l'opération ultérieure (par exemple,
fchdir(2), fstat(2)) n'a pas besoin des droits de lecture sur l'objet.
-
Si pathname est un lien symbolique et si l'attribut O_NOFOLLOW est
précisé, alors l'appel renvoie le descripteur de fichier d'un lien
symbolique. Ce descripteur de fichier peut être utilisé comme l'argument
dirfd lors d'appels aux fonctions fchownat(2), fstatat(2),
linkat(2) et readlinkat(2) avec un chemin d'accès vide pour permettre
à l'appel de s'exécuter sur le lien symbolique.
-
Si pathname renvoie à un point de montage automatique non encore
effectué, donc aucun autre système de fichiers n'y est monté, alors l'appel
renvoie un descripteur de fichier qui se rapporte au répertoire de montage
automatique sans effectuer de montage. fstatfs(2) peut alors être utilisé
pour déterminer s'il s'agit bien d'un point de montage automatique non non
effectué (.f_type == AUTOFS_SUPER_MAGIC).
-
Une utilisation de O_PATH sur des fichiers ordinaires consiste à fournir
l'équivalent de la fonctionnalité O_EXEC de POSIX.1. Cela nous permet
d'ouvrir un fichier sur lequel on a le droit d'exécution mais pas de
lecture, puis d'exécuter ce fichier selon des étapes comme suit :
-
char buf[PATH_MAX];
fd = open("un_programme", O_PATH);
snprintf(buf, PATH_MAX, "/proc/self/fd/%d", fd);
execl(buf, "un_programme", (char *) NULL);
-
Un descripteur de fichier O_PATH peut également être fourni comme
argument de fexecve(3).
- O_SYNC
-
Les opérations d'écriture dans le fichier se dérouleront selon les
conditions d'exécution des opérations E/S synchrones avec garantie
d'intégrité du fichier (contrairement à l'exécution des opérations E/S
synchrones avec garantie d'intégrité des données fournie par O_DSYNC.)
-
Au moment où write(2) (ou un appel similaire) renvoie une donnée, cette
donnée et les métadonnées associées au fichier ont été transmises au
matériel sur lequel s'exécute l'appel (autrement dit, comme si chaque appel
à write(2) était suivi d'un appel à fsync(2)). Consultez NOTES ci-dessous.
- O_TMPFILE (depuis Linux 3.11)
-
Créer un fichier temporaire sans nom. L’argument pathname indique un
répertoire ; un inœud sans nom sera créé dans le système de fichiers de ce
répertoire. Tout ce qui est écrit dans le fichier résultant sera perdu quand
le dernier descripteur de fichier sera fermé, à moins de donner un nom au
fichier.
-
O_TMPFILE doit être indiqué avec soit O_RDWR, soit O_WRONLY, et
facultativement O_EXCL. Si O_EXCL n’est pas indiqué, alors
linkat(2) peut être utilisé pour lier le fichier temporaire dans le
système de fichiers, le rendant permanent, en utilisant du code comme :
-
char chemin[PATH_MAX];
df = open("/chemin/vers/rép.", O_TMPFILE | O_RDWR,
S_IRUSR | S_IWUSR);
/* E/S du fichier sur 'fd'... */
linkat(fd, "", AT_FDCWD, "/chemin/du/fichier", AT_EMPTY_PATH);
/* Si l'appelant n'a pas la capacité CAP_DAC_READ_SEARCH (nécessaire
pour utiliser AT_EMPTY_PATH avec linkat(2)) et s'il existe un
système de fichiers proc(5) monté, l'appel linkat(2) ci-dessus peut
être remplacé par :
snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/chemin/du/fichier",
AT_SYMLINK_FOLLOW);
*/
-
Dans ce cas, l’argument mode d’open() détermine le mode de droits du
fichier, comme avec O_CREAT.
-
Indiquer O_EXCL en conjonction avec O_TMPFILE empêche de lier un
fichier temporaire dans le système de fichiers comme précédemment (remarquez
que la signification de O_EXCL dans ce cas est différente de la
signification habituelle de O_EXCL).
-
Les deux principaux cas d’utilisation de O_TMPFILE sont présentés
ci-dessous :
-
- •
-
Améliorer la fonctionnalité tmpfile(3) : création de fichiers temporaires
sans situation de compétition qui (1) sont automatiquement supprimés à la
fermeture ; (2) ne peuvent jamais être atteints par n’importe quel chemin ;
(3) ne sont pas exposés aux attaques de lien symbolique ; et (4) ne
nécessitent pas à l’appelant d’inventer des noms uniques.
- •
-
Créer un fichier initialement invisible, qui est ensuite peuplé de données
et ajusté aux attributs de système de fichiers adéquats (fchown(2),
fchmod(2), fsetxattr(2), etc.) avant d’être lié de façon atomique dans
le système de fichiers dans un état complètement formé (en utilisant
linkat(2) comme décrit précédemment).
-
O_TMPFILE nécessite une prise en charge par le système de fichiers
sous-jacent. Seule une partie des systèmes de fichiers Linux fournit cette
prise en charge. Dans l'implémentation initiale, la prise en charge était
assurée pour les systèmes de fichiers ext2, ext3, ext4, UDF, Minix et
tmpfs. La prise en charge d'autres systèmes de fichiers a ensuite été
ajoutée ainsi : XFS (Linux 3.15) ; Btrfs (Linux 3.16) ; F2FS (Linux 3.16) ;
et ubifs (Linux 4.9)
- O_TRUNC
-
Si le fichier existe, est un fichier ordinaire et que le mode d’accès permet
l’écriture (O_RDWR ou O_WRONLY), il sera tronqué à une longueur
nulle. Si le fichier est une FIFO ou un périphérique terminal, l'attribut
O_TRUNC est ignoré. Sinon, le comportement de O_TRUNC n'est pas
précisé.
creat()
L'appel creat() est équivalent à open() avec l'attribut flags égal
à O_CREAT|O_WRONLY|O_TRUNC.
openat()
L'appel système openat() fonctionne de la même façon que open(), les
différences étant décrites ici.
L'argument dirfd est utilisé avec l'argument pathname comme suit :
- •
-
Si le chemin fourni dans pathname est absolu, alors dirfd est ignoré.
- •
-
Si le chemin fourni dans pathname est un chemin relatif et si dirfd a
la valeur spéciale AT_FDCWD, alors pathname est interprété par rapport
au répertoire courant du processus appelant, comme dans open().
- •
-
Si pathname est un chemin relatif, il est interprété par rapport au
répertoire référencé par le descripteur de fichier dirfd (plutôt que par
rapport au répertoire courant du processus appelant, comme cela est fait par
open() pour un chemin relatif). Dans ce cas, dirfd doit être un
répertoire qui a été ouvert en lecture (O_RDONLY) ou en utilisant
l'attribut O_PATH.
Si le chemin fourni dans pathname est un chemin relatif et si dirfd
n'est pas un descripteur de fichier valable, il en résulte une erreur
(EBADF). (Spécifier un numéro de descripteur de fichier non valable dans
dirfd peut être utilisé comme moyen de s'assurer que pathname est
absolu.)
L'appel système openat2(2) est une extension de openat() et il fournit
un ensemble supplémentaire aux fonctionnalités de openat(). Il est
documenté à part dans openat2(2).
VALEUR RENVOYÉE
open(), openat() et creat() renvoient le nouveau descripteur de
fichier (un entier non négatif) s'ils réussissent. En cas d'erreur, ou -1
est renvoyé et errno est défini pour indiquer l'erreur.
ERREURS
open(), openat() et creat() peuvent échouer avec les erreurs
suivantes :
- EACCES
-
L'accès demandé au fichier est interdit, ou la permission de parcours pour
l'un des répertoires du chemin pathname est refusée, ou le fichier
n'existe pas encore et le répertoire parent ne permet pas
l'écriture. (Consultez aussi path_resolution(7).)
- EACCES
-
Lorsque O_CREAT est indiqué, le systcl protected_fifos ou
protected_regular est activé, le fichier existe déjà ou est une FIFO ou
un fichier ordinaire, le propriétaire du fichier n'est ni l'utilisateur
actuel, ni celui du répertoire qui le contient, et ce répertoire est
accessible en écriture et en exécution pour tout le monde. Pour plus de
détails, consultez les descriptions de /proc/sys/fs/protected_fifos et de
/proc/sys/fs/protected_regular dans proc(5).
- EBADF
-
(openat()) pathname est relatif mais dirfd n'est ni AT_FDCWD ni
un descripteur de fichier valable.
- EBUSY
-
O_EXCL était indiqué dans flags et pathname se rapporte à un
périphérique bloc utilisé par le système (par exemple, il est monté).
- EDQUOT
-
Si O_CREAT est indiqué, le fichier n'existe pas et le quota de blocs de
disque ou d'inœuds de l'utilisateur sur le système de fichiers a été
atteint.
- EEXIST
-
pathname existe déjà et O_CREAT et O_EXCL ont été indiqués.
- EFAULT
-
nom_chemin pointe en dehors de l'espace d'adressage accessible.
- EFBIG
-
Consultez EOVERFLOW.
- EINTR
-
Pendant qu'il était bloqué en attente de l'ouverture d'un périphérique lent
(par exemple, une FIFO ; consultez fifo(7)), l'appel a été interrompu par
un gestionnaire de signal ; consultez signal(7).
- EINVAL
-
Le système de fichiers ne gère pas l’attribut O_DIRECT. Consultez
NOTES pour de plus amples renseignements.
- EINVAL
-
Valeur incorrecte dans flags.
- EINVAL
-
O_TMPFILE a été indiqué dans flags, mais ni O_WRONLY ni O_RDWR
n’ont été indiqués.
- EINVAL
-
O_CREAT était indiqué dans flags et le composant final (« basename »)
du pathname du nouveau fichier n'est pas valable (il contient par exemple
des caractères non autorisés par le système de fichiers sous-jacent).
- EINVAL
-
Le composant final (« basename ») de pathname n'est pas valable (il
contient, par exemple, des caractères non autorisés par le système de
fichiers sous-jacent).
- EISDIR
-
Une écriture a été demandée alors que pathname correspond à un répertoire
(en fait, O_WRONLY ou O_RDWR ont été déclarés).
- EISDIR
-
pathname fait référence à un répertoire existant, O_TMPFILE et soit
O_WRONLY, soit O_RDWR, ont été indiqués dans flags, mais cette
version du noyau ne fournit pas la fonctionnalité O_TMPFILE.
- ELOOP
-
Trop de liens symboliques ont été rencontrés en parcourant nom_chemin.
- ELOOP
-
pathname était un lien symbolique, et flags indiquait O_NOFOLLOW
mais pas O_PATH.
- EMFILE
-
La limite par processus du nombre de descripteurs de fichiers ouverts a été
atteinte (voir la description de RLIMIT_NOFILE dans getrlimit(2)).
- ENAMETOOLONG
-
nom_chemin est trop long.
- ENFILE
-
La limite du nombre total de fichiers ouverts pour le système entier a été
atteinte.
- ENODEV
-
pathname correspond à un fichier spécial et il n'y a pas de périphérique
correspondant. (Ceci est un bogue du noyau Linux ; dans cette situation,
ENXIO devrait être renvoyé.)
- ENOENT
-
O_CREAT n'est pas positionné et le fichier nommé n'existe pas.
- ENOENT
-
Un des répertoires du chemin d'accès nom_chemin n'existe pas ou est un
lien symbolique pointant nulle part.
- ENOENT
-
pathname fait référence à un répertoire inexistant, O_TMPFILE et soit
O_WRONLY, soit O_RDWR, ont été indiqués dans flags, mais cette
version du noyau ne fournit pas la fonctionnalité O_TMPFILE.
- ENOMEM
-
Le fichier nommé est une FIFO, mais la mémoire du tampon de la FIFO ne peut
pas être allouée car la limite dure par processus d'allocation de mémoire
pour des tubes (pipes) a été atteinte et l'appelant n'est pas privilégié ;
voir pipe(7).
- ENOMEM
-
La mémoire disponible du noyau n'était pas suffisante.
- ENOSPC
-
pathname devrait être créé mais le périphérique concerné n'a plus assez
de place pour un nouveau fichier.
- ENOTDIR
-
Un élément du chemin d'accès utilisé comme répertoire dans pathname ne
l’est pas, ou l'attribut O_DIRECTORY est utilisé et pathname n'est pas
un répertoire.
- ENOTDIR
-
(openat()) pathname est un chemin relatif et le descripteur de fichier
dirfd est associé à un fichier, pas à un répertoire.
- ENXIO
-
O_NONBLOCK | O_WRONLY est positionné, le fichier nommé est une FIFO et
le processus n'a pas cette FIFO ouverte en lecture.
- ENXIO
-
Le fichier est un fichier spécial de périphérique et il n'existe aucun
périphérique correspondant.
- ENXIO
-
Le fichier est un socket de domaine UNIX.
- EOPNOTSUPP
-
Le système de fichiers contenant pathname ne prend pas en charge
O_TMPFILE.
- EOVERFLOW
-
pathname fait référence à un fichier ordinaire qui est trop grand pour
être ouvert. Cela arrive quand une application compilée sur une plate-forme
32 bits sans -D_FILE_OFFSET_BITS=64 essaie d'ouvrir un fichier dont la
taille dépasse (2^31)-1 octets ; consultez également O_LARGEFILE
ci-dessus. C'est l'erreur spécifiée par POSIX.1 ; avant Linux 2.6.24, Linux
fournissait l'erreur EFBIG dans ce cas.
- EPERM
-
L'attribut O_NOATIME est indiqué, mais l'UID effectif de l'appelant n'est
pas celui du propriétaire du fichier, et l'appelant n'est pas privilégié.
- EPERM
-
La lecture a été interrompue par un signal ; consultez fnctl(2).
- EROFS
-
Un accès en écriture est demandé alors que pathname réside sur un système
de fichiers en lecture seule.
- ETXTBSY
-
Une écriture a été demandée alors que pathname correspond à un fichier
exécutable actuellement utilisé.
- ETXTBSY
-
pathname se rapporte à un fichier actuellement utilisé comme fichier
d'échange et l'attribut O_TRUNC a été indiqué.
- ETXTBSY
-
pathname se rapporte à un fichier actuellement lu par le noyau (par
exemple pour charger un module ou du micro-code), et un accès en écriture a
été demandé.
- EWOULDBLOCK
-
L'attribut O_NONBLOCK est indiqué, et un bail incompatible est détenu sur
le fichier (consultez fcntl(2)).
VERSIONS
openat() a été ajouté dans Linux 2.6.16 ; la prise en charge de la
bibliothèque a été ajoutée dans la glibc 2.4.
STANDARDS
open(), creat() : SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
openat() : POSIX.1-2008.
openat2(2) est spécifique à Linux.
Les attributs O_DIRECT, O_NOATIME, O_PATH et O_TMPFILE sont
spécifiques à Linux. _GNU_SOURCE doit être définie pour obtenir leurs
définitions.
Les attributs O_CLOEXEC, O_DIRECTORY et O_NOFOLLOW ne sont pas
spécifiés dans POSIX.1-2001, mais le sont dans POSIX.1-2008. Depuis
glibc 2.12, leurs définitions peuvent être obtenues en définissant soit
_POSIX_C_SOURCE avec une valeur supérieure ou égale à 200809L, soit
_XOPEN_SOURCE avec une valeur supérieure ou égale à 700. Dans glibc 2.11
et les versions précédentes, les définitions peuvent être obtenues en
définissant _GNU_SOURCE.
Comme indiqué dans feature_test_macros(7), les macros de test de
fonctionnalités comme _POSIX_C_SOURCE, _XOPEN_SOURCE et _GNU_SOURCE
doivent être définies avant d'inclure n’importe quel fichier d'en-tête.
NOTES
Sous Linux, l'attribut O_NONBLOCK est parfois utilisé pour indiquer qu'on
veut ouvrir mais pas nécessairement dans l'intention de lire ou d'écrire. Il
est typiquement utilisé pour ouvrir des périphériques dans le but de
récupérer un descripteur de fichier pour l'utiliser avec ioctl(2).
L'effet (indéfini) de O_RDONLY | O_TRUNC varie selon
l'implémentation. Sur de nombreux systèmes, le fichier est effectivement
tronqué.
Notez que open() peut ouvrir des fichiers spéciaux mais creat() ne
peut pas en créer, il faut utiliser mknod(2) à la place.
Si un fichier est créé, ses horodatages st_atime, st_ctime,
st_mtime (respectivement heure de dernier accès, de dernière modification
d'état, et de dernière modification ; consultez stat(2)) sont définis à
l'heure actuelle, ainsi que les champs st_ctime et st_mtime du
répertoire parent. Sinon, si le fichier est modifié à cause de l'attribut
O_TRUNC, ses champs st_ctime et st_mtime sont remplis avec l'heure
actuelle.
Les fichiers du répertoire /proc/[pid]/fd affichent les descripteurs de
fichier ouverts du processus ayant l'identifiant pid. Les fichiers du
répertoire /proc/[pid]/fdinfo présentent encore plus d'informations sur
ces descripteurs de fichier. Voir proc(5) pour plus de détails sur ces
deux répertoires.
Le fichier d'en-tête <asm/fcntl.h> du noyau Linux ne définit pas
O_ASYNC ; son synonyme FASYNC (dérivé de BSD) l'est en revanche.
Description de fichier ouvert
Le terme « description de fichier ouvert » correspond à la terminologie
POSIX pour faire référence à des entrées dans la table des fichiers ouverts
du système. Dans d'autres contextes, cet objet est également appelé « objet
de fichier ouvert », « gestionnaire de fichier », « entrée de la table des
fichiers ouverts » ou encore, dans le jargon des développeurs du noyau,
struct file.
Lorsqu'un descripteur de fichiers est dupliqué (au moyen de dup(2) ou
d'un équivalent), la copie fait référence à la même description de fichier
ouvert que le descripteur de fichier d'origine. Les deux descripteurs de
fichier partagent donc la même position dans le fichier et les mêmes
attributs d'état. Un tel partage peut également se produire entre deux
processus : un processus enfant créé au moyen de fork(2) hérite des
copies des descripteurs de fichier de ses parents, et ces copies pointent
vers les mêmes descriptions de fichier ouvert.
Chaque opération open(2) sur un fichier crée une nouvelle description de
fichier ouvert ; ainsi, il peut y avoir plusieurs descriptions de fichier
ouvert correspondant à un inœud de fichier.
Sur Linux, on peut utiliser KCMP_FILE de kcmp(2) pour tester si deux
descripteurs de fichier (dans le même processus ou dans deux processus
différents) se rapportent à la même description de fichier ouvert.
E/S synchrones
L'option POSIX-1.2008 « E/S synchrones » décrit des variantes des E/S
synchrones, ainsi que plusieurs attributs de open() permettant d'en
contrôler le comportement : O_SYNC, O_DSYNC et O_RSYNC. Sans
chercher à savoir si une implémentation accepte cette option, elle doit au
moins prendre en charge l'utilisation de O_SYNC pour les fichiers
normaux.
Linux met en œuvre O_SYNC et O_DSYNC, mais pas O_RSYNC. De façon
plus ou moins correcte, la glibc définit O_RSYNC de façon à avoir la même
valeur que O_SYNC. (O_RSYNC est défini dans le fichier d'en-tête du
noyau Linux <asm/fcntl.h> de HP PA-RISC, mais il n'est pas
utilisé).
O_SYNC fournit l'exécution d'E/S synchrones avec garantie d'intégrité des
fichiers, ce qui signifie que les opérations d'écriture envoient les
données et les métadonnées associées au matériel. O_DSYNC fournit
l'exécution d'E/S synchrones avec garantie d'intégrité des données, ce
qui signifie que les opérations d'écriture envoient les données et les
métadonnées associées au matériel, mais en envoyant seulement les mises à
jour des métadonnées qui permettent d'assurer le bon déroulement d'une
opération de lecture ultérieure. L'exécution avec garantie d'intégrité des
données peut réduire le nombre d'accès au disque demandés par une
application qui ne nécessite pas l'exécution avec garantie d'intégrité des
fichiers.
Pour comprendre la différence entre ces deux types d'exécution, imaginez
deux extraits de métadonnées d'un fichier : l'horodatage de la dernière
modification (st_mtime) et la longueur du fichier. Toutes les opérations
d'écriture modifieront l'horodatage de la dernière modification, mais seules
les écritures en fin de fichier modifieront la longueur. L'horodatage de
dernière modification n'est pas nécessaire pour garantir une lecture
correcte du fichier, contrairement à la longueur. Ainsi, O_DSYNC
transmettrait seulement la métadonnée relative à la longueur du fichier
(quand O_SYNC y ajouterait l'horodatage de dernière modification).
Avant Linux 2.6.33, Linux mettait seulement en œuvre l'attribut O_SYNC de
open(). Cependant, lorsque cet attribut était indiqué, la plupart des
systèmes de fichiers fournissait des fonctionnalités équivalentes à
l'exécution des E/S synchrones avec garantie de l'intégrité des données
(autrement dit, O_SYNC était de fait mis en œuvre comme O_DSYNC).
A partir de Linux 2.6.33, une véritable prise de charge de O_SYNC est
fournie. Cependant, pour assurer la compatibilité ascendante binaire,
O_DSYNC a été défini avec la même valeur que le O_SYNC « historique »,
et O_SYNC a été défini comme un nouvel attribut (de deux bits) qui
comprend l'attribut O_DSYNC. Ceci permet d'assurer que les applications
compilées avec les nouveaux en-têtes auront au moins la sémantique de
O_DSYNC avant Linux 2.6.33.
différences entre bibliothèque C et noyau
Depuis la glibc 2.26, la fonction enveloppe de la glibc de open() utilise
l'appel système openat() au lieu de l'appel système open() du
noyau. Pour certaines architectures, cela est aussi vrai avant la
glibc 2.26.
NFS
Plusieurs problèmes se posent avec le protocole NFS, concernant entre autres
O_SYNC, et O_NDELAY.
Sur les systèmes de fichiers NFS, où la correspondance d'UID est activée,
open() peut renvoyer un descripteur de fichier alors qu'une requête
read(2) par exemple sera refusée avec le code d'erreur EACCES. En
effet, le client a effectué open() en vérifiant les autorisations
d'accès, mais la correspondance d'UID est calculée par le serveur au moment
des requêtes de lecture ou d'écriture.
FIFO
Ouvrir les blocs de fin de FIFO en lecture et écriture jusqu'à ce que
l'autre fin soit également ouverte (par un autre processus ou un autre
thread). Voir fifo(7) pour plus de détails.
Mode d’accès au fichier
Contrairement aux autres valeurs qui peuvent être indiquées dans flags,
les valeurs du mode d'accès O_RDONLY, O_WRONLY et O_RDWR ne sont
pas des bits individuels. Ils définissent l'ordre des deux bits de poids
faible de flags, et ont pour valeur respective 0, 1 et 2. En d'autres
termes, l'association O_RDONLY | O_WRONLY est une erreur logique et n'a
certainement pas la même signification que O_RDWR.
Linux réserve le sens suivant au mode 3 d'accès spécial et non standard (en
binaire, 11) de l'attribut : vérification des droits en lecture et écriture
du fichier, et renvoi d'un descripteur qui ne peut être utilisé ni en
lecture, ni en écriture. Ce mode d'accès non standard est utilisé par
certains pilotes Linux afin de renvoyer un descripteur qui n'est destiné
qu'à des opérations ioctl(2) propres aux périphériques.
Justification des appels openat() et des API des descripteurs de fichier de répertoires
openat() et les autres appels système similaires, ainsi que les fonctions
de bibliothèques qui reçoivent pour argument un descripteur de fichier de
répertoire (c'est-à-dire, 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) et scandirat(3)) gèrent deux problèmes
avec les anciennes interfaces. L'explication est ici donnée dans le contexte
de l'appel openat(), mais elle est semblable pour les autres interfaces.
Tout d'abord, openat() permet à une application d'éviter les problèmes
d'accès concurrents lors de l'utilisation de open() pour ouvrir des
fichiers dans des répertoires autres que le répertoire courant. Ces
problèmes sont dus au fait que l'un des composants du chemin donné à
open() peut être modifié parallèlement à l'appel open(). Supposons par
exemple qu'on veuille créer le fichier dir1/dir2/xxx.dep alors que le
fichier dir1/dir2/xxx existe. Le problème est qu'entre la vérification de
son existence et l'étape de création du fichier, dir1 ou dir2 (qui
pourraient être des liens symboliques) pourraient être modifiés pour pointer
vers un autre endroit. De tels problèmes peuvent être évités en ouvrant un
descripteur de fichier sur le répertoire cible, puis en fournissant ce
descripteur comme argument dirfd de (disons) fstatat(2) et
openat(). L'utilisation du descripteur de fichier dirfd a également
d'autres avantages :
- •
-
le descripteur de fichier est une référence stable au répertoire, même si le
répertoire est renommé ;
- •
-
le descripteur de fichier ouvert empêche le système de fichiers sous-jacent
d'être démonté quand un processus détient un répertoire en cours de
fonctionnement sur le système de fichiers.
Enfin, openat() permet d'implémenter un « répertoire courant » par
thread, grâce à des descripteurs de fichier maintenus par
l'application. Cette fonctionnalité peut également être obtenue en jouant
avec /proc/self/fd/dirfd, mais de façon moins efficace.
L'argument dirfd de ces API peut être obtenu par l'utilisation de
open() ou de openat() pour ouvrir un répertoire (avec le drapeau
O_RDONLY ou O_PATH). Sinon, un tel descripteur de fichier peut être
obtenu en appliquant un dirfd(3) au flux d'un répertoire créé avec
opendir(3).
Quand on donne aux API un argument dirfd de AT_FDCWD ou qu'un chemin
indiqué est absolu, ils gèrent leur argument de chemin de la même manière
que les API conventionnelles correspondantes. Toutefois dans ce cas,
plusieurs API ont un argument flags qui offre un accès à cette
fonctionnalité non disponible avec les interfaces conventionnelles
correspondantes.
O_DIRECT
L'attribut O_DIRECT peut imposer des restrictions d'alignement pour la
longueur et l'adresse des tampons de l'espace utilisateur et des décalages
de fichier pour les entrées-sorties. Sous Linux, les restrictions
d'alignement varient en fonction du système de fichiers et de la version du
noyau, et il peut aussi ne pas y en avoir. La manipulation des
entrées-sorties O_DIRECT mal alignées varie aussi ; elles peuvent soit
échouer avec l'erreur EINVAL soit se replier sur des entrées-sorties
mises en tampon.
Depuis Linux 6.1, la prise en charge de O_DIRECT et les restrictions
d'alignement pour un fichier peuvent être recherchées avec statx(2) en
utilisant l'attribut STATX_DIOALIGN. La prise en charge de
STATX_DIOALIGN varie selon le système de fichiers ; consultez
statx(2).
Certains systèmes de fichiers fournissent leur propre interface pour
rechercher les restrictions d'alignement de O_DIRECT, par exemple
l'opération XFS_IOC_DIOINFO de xfsctl(3). STATX_DIOALIGN devrait
être utilisé à la place quand il est disponible.
Si aucun de ces interfaces n'est disponible, alors la prise en charge
directe des entrées-sorties et les restrictions d'alignement peuvent
uniquement être présumées à partir des caractéristiques connues du système
de fichiers, du fichier individuel, des périphériques de stockage
sous-jacents et de la version du noyau. Dans Linux 2.4, la plupart des
systèmes de fichiers basés sur des périphériques bloc requièrent que
l'adresse du fichier et la longueur et l'adresse mémoire de tous les
segments d'entrées-sorties soient des multiples de la taille de bloc du
système de fichiers (habituellement 4096 octets). Dans Linux 2.6.0, cela a
été assoupli à la taille du bloc logique du périphérique bloc
(habituellement 512 octets). La taille de bloc logique d'un périphérique
bloc peut être déterminée avec l'opération BLKSSZGET de ioctl(2) ou
avec la commande shell suivante :
blockdev --getss
Les E/S O_DIRECT ne devraient jamais être exécutées en même temps que
l'appel système fork(2), si le tampon mémoire est une projection privée
(c'est-à-dire n'importe quelle projection en mémoire créée avec l'attribut
MAP_PRIVATE de mmap(2), y compris la mémoire allouée sur le tas et les
tampons alloués de façon statique). Toutes ces E/S, qu'elles soient soumises
par l'intermédiaire d'une interface d'E/S asynchrone ou depuis un autre
thread du processus, devraient être achevées avant l'appel de fork(2). En
cas d'échec, les conséquences pourraient être une corruption de mémoire ou
un comportement imprévisible dans les processus père et fils. Cette
restriction ne s'applique pas quand le tampon mémoire pour les E/S
O_DIRECT a été créé en utilisant shmat(2) ou mmap(2) avec
l'attribut MAP_SHARED. Cette restriction ne s'applique pas non plus quand
le tampon mémoire a été configuré comme MADV_DONTFORK avec madvise(2),
en s'assurant qu'il ne sera pas disponible au fils après fork(2).
L'attribut O_DIRECT a été introduit par SGI IRIX, qui a des restrictions
d'alignement identiques à Linux 2.4. IRIX a aussi un appel fcntl(2) pour
obtenir les alignements et tailles appropriés. FreeBSD 4.x a introduit un
attribut du même nom, mais sans les restrictions d'alignement.
La gestion de O_DIRECT a été ajoutée dans Linux 2.4.10. Les noyaux Linux
plus anciens ignorent simplement cet attribut. Certains systèmes de fichiers
peuvent ne pas gérer cet attribut et open() échouera avec l'erreur
EINVAL s'il est utilisé.
Les applications devraient éviter de mélanger des entrées-sorties
O_DIRECT et normales pour le même fichier, en particulier sur des régions
d'un même fichier qui se recouvrent. Même si le système de fichiers gère les
problèmes de cohérence dans cette situation, le débit global
d'entrées-sorties sera moindre que si un seul mode était utilisé. De la même
façon, les applications devraient éviter de mélanger l'utilisation de
mmap(2) et d'entrées-sorties directes pour les mêmes fichiers.
Le comportement de O_DIRECT avec NFS diffère des systèmes de fichiers
locaux. Les anciens noyaux, ou les noyaux configurés d'une certaine façon,
peuvent ne pas gérer cette combinaison. Le protocole NFS ne gère pas le
passage de l'attribut au serveur, les entrées-sorties O_DIRECT ne font
donc que le cache des pages du client ; le serveur pourra toujours utiliser
un cache pour les entrées-sorties. Le client demande au serveur de rendre
les entrées-sorties synchrones pour préserver la sémantique synchrone de
O_DIRECT. Certains serveurs fonctionnent mal dans ces circonstances, tout
particulièrement si les entrées-sorties sont de petite taille. Certains
serveurs peuvent aussi être configurés pour mentir aux clients et indiquer
que les entrées-sorties ont atteint un espace de stockage stable ; ceci
évitera la perte de performance en augmentant les risques pour l'intégrité
des données en cas de problème d'alimentation du serveur. Le client NFS
Linux n'a pas de restriction d'alignement pour les entrées-sorties
O_DIRECT.
En résumé, O_DIRECT est un outil potentiellement puissant qui doit être
utilisé avec précaution. Les applications devraient utiliser O_DIRECT
comme une option pour améliorer les performances et qui est désactivée par
défaut.
BOGUES
Actuellement, il n'est pas possible d'activer les entrées-sorties contrôlées
par les signaux en indiquant O_ASYNC lors de l'appel open() ; il faut
utiliser fcntl(2) pour activer cet attribut.
Deux codes d’erreur différents – EISDIR et ENOENT — doivent être
vérifiés pour essayer de déterminer si le noyau prend en charge la
fonctionnalité O_TMPFILE.
Quand O_CREAT et O_DIRECTORY sont indiqués dans flags et que le
fichier indiqué par pathname n'existe pas, open() créera un fichier
ordinaire (c'est-à-dire que O_DIRECTORY est ignoré).
VOIR AUSSI
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)
TRADUCTION
La traduction française de cette page de manuel a été créée par
Christophe Blaess <https://www.blaess.fr/christophe/>,
Stéphan Rafin <stephan.rafin@laposte.net>,
Thierry Vignaud <tvignaud@mandriva.com>,
François Micaux,
Alain Portal <aportal@univ-montp2.fr>,
Jean-Philippe Guérard <fevrier@tigreraye.org>,
Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>,
Julien Cristau <jcristau@debian.org>,
Thomas Huriaux <thomas.huriaux@gmail.com>,
Nicolas François <nicolas.francois@centraliens.net>,
Florentin Duneau <fduneau@gmail.com>,
Simon Paillard <simon.paillard@resel.enst-bretagne.fr>,
Denis Barbier <barbier@debian.org>,
David Prévot <david@tilapin.org>,
Frédéric Hantrais <fhantrais@gmail.com>,
Jean-Philippe MENGUAL <jpmengual@debian.org>
et
Jean-Pierre Giraud <jean-pierregiraud@neuf.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la
GNU General Public License version 3
concernant les conditions de copie et
de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à
Index
- NOM
-
- BIBLIOTHÈQUE
-
- SYNOPSIS
-
- DESCRIPTION
-
- creat()
-
- openat()
-
- openat2(2)
-
- VALEUR RENVOYÉE
-
- ERREURS
-
- VERSIONS
-
- STANDARDS
-
- NOTES
-
- Description de fichier ouvert
-
- E/S synchrones
-
- différences entre bibliothèque C et noyau
-
- NFS
-
- FIFO
-
- Mode d’accès au fichier
-
- Justification des appels openat() et des API des descripteurs de fichier de répertoires
-
- O_DIRECT
-
- BOGUES
-
- VOIR AUSSI
-
- TRADUCTION
-
This document was created by
man2html,
using the manual pages.
Time: 04:02:52 GMT, May 18, 2024