Ubuntu Manpage: open, openat, creat - Ouvrir ou créer éventuellement un fichier

nom
synopsis
description
valeur renvoyée
erreurs
versions
conformité
notes
bogues
voir aussi
colophon
traduction

Provided by: manpages-fr-dev_3.65d1p1-1_all

NOM

       open, openat, creat - Ouvrir ou créer éventuellement un fichier

SYNOPSIS

       #include <sys/types.h>
       #include <sys/stat.h>
       #include <fcntl.h>

       int open(const char *pathname, int flags);
       int open(const char *pathname, int flags, mode_t mode);

       int creat(const char *pathname, mode_t mode);

       int openat(int dirfd, const char *pathname, int flags);
       int openat(int dirfd, const char *pathname, int flags, mode_t mode);

   Exigences de macros de test de fonctionnalités pour la glibc (consultez feature_test_macros(7)) :

       openat():
           Depuis la glibc 2.10 :
               _XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L
           Avant la glibc 2.10 :
               _ATFILE_SOURCE

DESCRIPTION

Étant donné le chemin pathname d'un fichier, open() renvoie un descripteur de fichier (petit entier
positif ou nul) qui pourra ensuite être utilisé dans d'autres appels système (read(2), write(2),
lseek(2), fcntl(2), etc.). Le descripteur de fichier renvoyé par un appel réussi sera le plus petit
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 entrée enregistre la position dans le fichier et les attributs d'état du
fichier (modifiables par l'opération F_SETFL de fcntl(2)). Un descripteur de fichier est une référence à
l'une de ces entrées ; cette référence n'est pas modifiée si pathname est ensuite supprimé ou modifié
pour correspondre à un autre fichier. La nouvelle description de fichier ouvert n'est initialement
partagée avec aucun autre processus, mais ce partage peut apparaître après un fork(2).

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, O_TRUNC et O_TTY_INIT. 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 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 ». Initialement, et avant chaque write(2), la tête de
lecture/écriture est placée à la fin du fichier comme avec lseek(2). 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
supporte pas l'opération d'ajout de données dans un fichier, aussi le noyau du client est obligé
de la simuler, avec un risque de 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 fcntl(2) F_SETFD 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 fcntl(2) F_SETFD 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
execute 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 fils créé par fork(2).
(Ce type 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
Créer le fichier s'il n'existe pas. Le possesseur (UID) du fichier est renseigné avec l'UID
effectif du processus. Le groupe propriétaire (GID) du fichier est le GID effectif du processus ou
le GID du répertoire parent (cela dépend du système de fichiers, des options de montage, du mode
du répertoire parent ; consultez les options de montage bsdgroups et sysvgroups décrites dans la
page mount(8)).

Le paramètre mode indique les droits à utiliser si un nouveau fichier est créé. Ce paramètre doit
être fourni quand O_CREAT ou O_TMPFILE sont indiqués dans flags ; si ni O_CREAT ni O_TMPFILE ne
sont précisés, mode est ignoré. Les droits effectifs sont modifiées par le umask du processus : la
véritable valeur utilisée est (mode & ~umask). Remarquez que ce 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.

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
à la page raw(8).

O_DIRECTORY
Si pathname n'est pas un répertoire, l'ouverture échoue. Cet attribut fut ajouté dans la version
2.1.126 du noyau, pour éviter des problèmes de dysfonctionnement si opendir(3) est invoqué sur une
FIFO ou un périphérique de 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.

Lorsque ces deux attributs sont spécifiés, les liens symboliques ne sont pas suivis : si pathname
est un lien symbolique, open() échouera quelque 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 fichier atomique 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.pour vérifier si le nombre de
liens a augmenté jusqu'à 2. Ne pas utiliser la valeur de retour de link(2).

O_LARGEFILE
(LFS) Permet 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 l'heure de dernier accès au fichier (champ st_atime de l'inœud) quand le
fichier est lu avec read(2). Ce 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 pathname est un lien symbolique, l'ouverture échoue. C’est une extension FreeBSD, qui fut
ajoutée à Linux dans la version 2.1.126. Les liens symboliques se trouvant dans le chemin d'accès
proprement dit seront suivis normalement. Consultez également O_PATH dans la suite du document.

O_NONBLOCK ou O_NDELAY
Le fichier est ouvert en mode « non-bloquant ». Ni la fonction open() ni aucune autre opération
ultérieure sur ce fichier ne laissera le processus appelant en attente. 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), 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) (à partir de Linux 3.5); fstat(2) (à partir de Linux 3.6).

* 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
and 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() ».

* Transmettre le descripteur de fichier à un autre processus via une socket de domaine UNIX
(consultez SCM_RIGHTS dans unix(7)).

Lorsque O_PATH est précisé dans flags, seuls les bits O_DIRECTORY et O_NOFOLLOW de l'attribut sont
pris en compte.

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.

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
s’est pas indiqué, alors linkat(2) peut être utilisé pour lier le fichier temporaire dans le
système de fichier, 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);

/* Entrée et sortie du fichier sur « df »… */

snprintf(chemin, PATH_MAX, "/proc/self/fd/%d", df);
linkat(AT_FDCWD, chemin, AT_FDCWD, "/chemin/vers/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 leur 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 (chown(2), chmod(2), fsetxattr(2), etc.) avant d’être
automatiquement lié 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. Seul 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 shmem.
XFS est également pris en charge depuis Linux 3.15.

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é. Sur
de nombreuses versions de Linux, il sera ignoré ; sur d'autres versions il déclenchera une
erreur).

creat()
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.

Si le chemin donné dans pathname est relatif, il est interprété par rapport au répertoire auquel le
descripteur de fichier dirfd fait référence (et non par rapport au répertoire courant du processus, comme
pour open()).

Si 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 absolu, dirfd est ignoré.

VALEUR RENVOYÉE

       open(),  openat()  et  creat() renvoient le nouveau descripteur de fichier s'ils réussissent, ou -1 s'ils
       échouent, auquel cas errno contient le code d'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).)

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 pathname 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.

EISDIR Une écriture a été demandée alors que pathname correspond à un répertoire (en fait, O_WRONLY ou
O_RDWR ont été demandé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 pathname.

ELOOP pathname était un lien symbolique, et flags indiquait O_NOFOLLOW mais pas O_PATH.

EMFILE Le processus a déjà ouvert le nombre maximal de fichiers.

ENAMETOOLONG
pathname est trop long.

ENFILE La limite du nombre total de fichiers ouverts sur le système 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 est absent et le fichier n'existe pas. Ou un répertoire du chemin d'accès pathname
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 Pas assez de mémoire pour le noyau.

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 pathname n'est pas un répertoire, ou l'attribut O_DIRECTORY est
utilisé et pathname n'est pas un répertoire.

ENXIO O_NONBLOCK | O_WRONLY est indiqué, le fichier est une FIFO et le processus n'a pas de fichier
ouvert en lecture. Ou le fichier est un nœud spécial et il n'y a pas de périphérique
correspondant.

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 bits ; consultez également O_LARGEFILE
ci-dessus. C'est l'erreur spécifiée par POSIX.1-2001 ; dans les noyaux antérieurs à la version
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 le propriétaire du
fichier, et l'appelant n'est pas privilégié (CAP_FOWNER).

EROFS Un accès en écriture est demandé alors que pathname réside sur un système de fichiers en lecture
seule.

ETXTBSY
On a demandé une écriture alors que pathname correspond à un fichier exécutable actuellement
utilisé.

EWOULDBLOCK
L'attribut O_NONBLOCK est indiqué, et un bail incompatible est détenu sur le fichier (consultez
fcntl(2)).

Les erreurs supplémentaires suivantes peuvent également se produire pour openat() :

EBADF dirfd n'est pas un descripteur de fichier valable.

ENOTDIR
pathname est relatif, et le descripteur de fichier dirfd est associé à un fichier, pas à un
répertoire.

VERSIONS

       openat() a été ajouté au noyau Linux dans sa version 2.6.16 ; la glibc le gère depuis la version 2.4.

CONFORMITÉ

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

       openat() : POSIX.1-2008.

       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 indique que l'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.

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 oeuvre O_SYNC et O_DSYNC, mais pas O_RSYNC. (De façon plus ou moins correcte, glibc définit
O_RSYNC de façon à avoir la même valeur que O_SYNC.)

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 metadonné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 metadonné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 oeuvre 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 oeuvre 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 sur les noyaux antérieurs à 2.6.33.

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.

mode 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 d'accès spécial et non-standard 3 (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ée qu'à des opérations ioctl(2) propres aux
périphériques.

Justification des appels openat() et des APIs 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, faccessat(2), fanotify_mark(2),
fchmodat(2), fchownat(2), fstatat(2), futimesat(2), linkat(2), mkdirat(2), mknodat(2),
name_to_handle_at(2), readlinkat(2), renameat(2), symlinkat(2), unlinkat(2), utimensat(2), mkfifoat(3) et
scandirat(3)) sont pris en charge pour deux raisons. L'explication est ici donnée dans le contexte de
l'appel openat(), mais des arguments analogues sont valables 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(). 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 openat().

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.

O_DIRECT
L'attribut O_DIRECT peut imposer, pour des raisons d'alignement, des restrictions sur la longueur et
l'adresse des tampons de l'espace utilisateur et des déplacements dans les entrées-sorties de fichiers.
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. Cependant, il n'y a pas actuellement d'interface indépendante
du système de fichiers qui permette aux applications de découvrir ces restrictions pour un fichier ou
système de fichiers donné. Certains systèmes de fichiers fournissent leur propre interface pour faire
cela, comme par exemple l'opération XFS_IOC_DIOINFO de xfsctl(3).

Sous Linux 2.4, la taille des transferts, l'alignement du tampon et la position dans le fichier doivent
être des multiples de la taille de blocs logiques du système de fichiers. Sous Linux 2.6, un alignement
sur des multiples de 512 octets est suffisant.

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é dans Linux 2.4.10. Les noyaux plus anciens ignorent simplement cet
attribut. Certains système de fichiers peuvent ne pas supporter cet attribut et open() échouera avec
l'erreur EINVAL s'il a été 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, qui devrait
être désactivée par défaut.

« Ce qui m'a toujours dérangé avec O_DIRECT est que toute l'interface est stupide et a
probablement été conçue par un singe dérangé, sous l'influence de substances psychotropes
puissantes. » — Linus.

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.

VOIR AUSSI

       chmod(2),  chown(2),  close(2),  dup(2),  fcntl(2),  link(2),  lseek(2),  mknod(2),  mmap(2),   mount(2),
       open_by_name_at(2),  read(2),  socket(2),  stat(2),  umask(2),  unlink(2),  write(2),  fopen(3), fifo(7),
       path_resolution(7), symlink(7)

COLOPHON

       Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description du projet et des
       instructions     pour     signaler     des     anomalies    peuvent    être    trouvées    à    l'adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par
       l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.

       Christophe       Blaess       <http://www.blaess.fr/christophe/>      (1996-2003),      Alain      Portal
       <http://manpagesfr.free.fr/> (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de  traduction  de
       Debian (2006-2009).

       Veuillez  signaler  toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par
       un rapport de bogue sur le paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C
       <section> <page_de_man> ».