.\" 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 "20 avril 2014" Linux "Manuel du programmeur Linux" .SH NOM open, openat, creat \- Ouvrir ou créer éventuellement un fichier .SH SYNOPSIS .nf \fB#include \fP \fB#include \fP \fB#include \fP .sp \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 \fBint creat(const char *\fP\fIpathname\fP\fB, mode_t \fP\fImode\fP\fB);\fP .sp \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 .fi .sp .in -4n Exigences de macros de test de fonctionnalités pour la glibc (consultez \fBfeature_test_macros\fP(7))\ : .in .sp \fBopenat\fP(): .PD 0 .ad l .RS 4 .TP 4 Depuis la glibc 2.10\ : _XOPEN_SOURCE\ >=\ 700 || _POSIX_C_SOURCE\ >=\ 200809L .TP Avant la glibc 2.10\ : _ATFILE_SOURCE .RE .ad .PD .SH DESCRIPTION Étant donné le chemin \fIpathname\fP d'un fichier, \fBopen\fP() renvoie un descripteur de fichier (petit entier positif ou nul) qui pourra ensuite être utilisé dans d'autres appels système (\fBread\fP(2), \fBwrite\fP(2), \fBlseek\fP(2), \fBfcntl\fP(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. .PP Par défaut, le nouveau descripteur de fichier est configuré pour rester ouvert après un appel à \fBexecve\fP(2) (son attribut \fBFD_CLOEXEC\fP décrit dans \fBfcntl\fP(2) est initialement désactivé). L'attribut \fBO_CLOEXEC\fP 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 \fBlseek\fP(2)). .PP Un appel à \fBopen\fP() crée une nouvelle \fIdescription de fichier ouvert\fP, 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 \fBF_SETFL\fP de \fBfcntl\fP(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 \fIpathname\fP 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 \fBfork\fP(2). .PP Le paramètre \fIflags\fP est l'un des éléments \fBO_RDONLY\fP, \fBO_WRONLY\fP ou \fBO_RDWR\fP qui réclament respectivement l'ouverture du fichier en lecture seule, écriture seule, ou lecture/écriture. .\" 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. .\" De plus, zéro ou plusieurs attributs de création de fichier et attributs d'état de fichier peuvent être indiqués dans \fIflags\fP avec un OU binaire. Les \fIattributs de création de fichier\fP sont \fBO_CLOEXEC\fP, \fBO_CREAT\fP, \fBO_DIRECTORY\fP, \fBO_EXCL\fP, \fBO_NOCTTY\fP, \fBO_NOFOLLOW\fP, \fBO_TMPFILE\fP, \fBO_TRUNC\fP et \fBO_TTY_INIT\fP. Les \fIattributs d'état de fichier\fP 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 \fBfcntl\fP(2) pour plus de précisions. La liste complète des attributs de création et d'état de fichier est la suivante. .TP \fBO_APPEND\fP .\" For more background, see .\" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453946 .\" http://nfs.sourceforge.net/ Le fichier est ouvert en mode «\ ajout\ ». Initialement, et avant chaque \fBwrite\fP(2), la tête de lecture/écriture est placée à la fin du fichier comme avec \fBlseek\fP(2). Il y a un risque d'endommager le fichier lorsque \fBO_APPEND\fP 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. .TP \fBO_ASYNC\fP Déclencher un signal (\fBSIGIO\fP par défaut, mais peut être changé via \fBfcntl\fP(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 \fBfcntl\fP(2) pour plus de détails. Consultez aussi \fBBOGUES\fP ci\-dessous. .TP \fBO_CLOEXEC\fP (depuis Linux\ 2.6.23) .\" NOTE! several otehr man pages refer to this text 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 \fBfcntl\fP(2) \fBF_SETFD\fP pour positionner l'attribut \fBFD_CLOEXEC\fP. .\" This flag fixes only one form of the race condition; .\" The race can also occur with, for example, descriptors .\" returned by accept(), pipe(), etc. Notez que le recours à cet attribut est indispensable pour certains programmes multithreadés. En effet, l'utilisation d'une opération \fBfcntl\fP(2) \fBF_SETFD\fP pour positionner l'attribut \fBFD_CLOEXEC\fP 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 \fBfcntl\fP(2) au moment où un autre thread execute \fBfork\fP(2) suivi de \fBexecve\fP(2). Selon l'ordre dans lequel ces opérations s'exécutent, cette concurrence peut aboutir à ce que le descripteur de fichier renvoyé par \fBopen\fP() soit involontairement mis à disposition du programme exécuté par le processus fils créé par \fBfork\fP(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 \fBO_CLOEXEC\fP pour régler ce problème.) .TP \fBO_CREAT\fP .\" As at 2.6.25, bsdgroups is supported by ext2, ext3, ext4, and .\" XFS (since 2.6.14). 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 \fIbsdgroups\fP et \fIsysvgroups\fP décrites dans la page \fBmount\fP(8)). .RS .PP Le paramètre \fImode\fP indique les droits à utiliser si un nouveau fichier est créé. Ce paramètre doit être fourni quand \fBO_CREAT\fP ou \fBO_TMPFILE\fP sont indiqués dans \fIflags\fP\ ; si ni \fBO_CREAT\fP ni \fBO_TMPFILE\fP ne sont précisés, \fImode\fP est ignoré. Les droits effectifs sont modifiées par le \fIumask\fP du processus\ : la véritable valeur utilisée est \fI(mode\ &\ ~umask)\fP. Remarquez que ce mode ne s'applique qu'aux accès ultérieurs au fichier nouvellement créé. L'appel \fBopen\fP() qui crée un fichier dont le mode est en lecture seule fournira quand même un descripteur de fichier en lecture et écriture. .PP Les constantes symboliques suivantes sont disponibles pour \fImode\fP\ : .TP 9 \fBS_IRWXU\fP 00700 L'utilisateur (propriétaire du fichier) a les autorisations de lecture, écriture, exécution. .TP \fBS_IRUSR\fP 00400 L'utilisateur a l'autorisation de lecture. .TP \fBS_IWUSR\fP 00200 L'utilisateur a l'autorisation d'écriture. .TP \fBS_IXUSR\fP 00100 L'utilisateur a l'autorisation d'exécution. .TP \fBS_IRWXG\fP 00070 Le groupe a les autorisations de lecture, écriture, exécution. .TP \fBS_IRGRP\fP 00040 Le groupe a l'autorisation de lecture. .TP \fBS_IWGRP\fP 00020 Le groupe a l'autorisation d'écriture. .TP \fBS_IXGRP\fP 00010 Le groupe a l'autorisation d'exécution. .TP \fBS_IRWXO\fP 00007 Tout le monde a les autorisations de lecture, écriture, exécution. .TP \fBS_IROTH\fP 00004 Tout le monde a l'autorisation de lecture. .TP \fBS_IWOTH\fP 00002 Tout le monde a l'autorisation d'écriture. .TP \fBS_IXOTH\fP 00001 Tout le monde a l'autorisation d'exécution. .RE .TP \fBO_DIRECT\fP (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 \fBO_DIRECT\fP 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 \fBO_SYNC\fP que les données et métadonnées sont transférées. Pour garantir des entrées\-sorties synchrones, l'attribut \fBO_SYNC\fP doit être utilisé en plus de l'attribut \fBO_DIRECT\fP. Consultez la section \fBNOTES\fP ci\-dessous. .sp Une interface à la sémantique similaire (mais dépréciée) pour les périphériques blocs est décrite à la page \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. Si \fIpathname\fP 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 \fBopendir\fP(3) est invoqué sur une FIFO ou un périphérique de bande. .TP \fBO_DSYNC\fP 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 \fIdonnées\fP. Au moment où \fBwrite\fP(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 à \fBwrite\fP(2) était suivi d'un appel à \fBfdatasync\fP(2)). \fIConsultez NOTES ci\-dessous\fP. .TP \fBO_EXCL\fP S'assurer que cet appel crée le fichier\ : si cet attribut est spécifié en conjonction avec \fBO_CREAT\fP et si le fichier \fIpathname\fP existe déjà, \fBopen\fP() échouera. .\" POSIX.1-2001 explicitly requires this behavior. Lorsque ces deux attributs sont spécifiés, les liens symboliques ne sont pas suivis\ : si \fIpathname\fP est un lien symbolique, \fBopen\fP() échouera quelque soit l'endroit où pointe le lien symbolique. En général, le comportement de \fBO_EXCL\fP est indéterminé s'il est utilisé sans \fBO_CREAT\fP. Il existe une exception toutefois\ : à partir de Linux\ 2.6, \fBO_EXCL\fP peut être utilisé sans \fBO_CREAT\fP si \fIpathname\fP 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é), \fBopen\fP() échoue avec l'erreur \fBEBUSY\fP. Sur les systèmes de fichiers NFS, \fBO_EXCL\fP 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'\fBO_EXCL\fP 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 \fBO_EXCL\fP 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 \fBlink\fP(2) pour créer un lien sur un fichier de verrouillage. Si \fBlink\fP(2) renvoie 0, le verrouillage est réussi. Sinon, utiliser \fBstat\fP(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 \fBlink\fP(2). .TP \fBO_LARGEFILE\fP (LFS) Permet d'ouvrir des fichiers dont la taille ne peut pas être représentée dans un \fIoff_t\fP (mais peut l'être dans un \fIoff64_t\fP). La macro \fB_LARGEFILE64_SOURCE\fP doit être définie (avant d'inclure \fItout\fP fichier d'en\(hytête) pour obtenir cette définition. Définir la macro \fB_FILE_OFFSET_BITS\fP à 64 est la méthode à favoriser pour accéder à des grands fichiers sur des systèmes 32\ bits, plutôt que d'utiliser \fBO_LARGEFILE\fP (consultez \fBfeature_test_macros\fP(7)). .TP \fBO_NOATIME\fP (depuis Linux\ 2.6.8) .\" The O_NOATIME flag also affects the treatment of st_atime .\" by mmap() and readdir(2), MTK, Dec 04. Ne pas mettre à jour l'heure de dernier accès au fichier (champ \fIst_atime\fP de l'inœud) quand le fichier est lu avec \fBread\fP(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. .TP \fBO_NOCTTY\fP Si \fIpathname\fP correspond à un périphérique de terminal \(em\ consultez \fBtty\fP(4)\ \(em, il ne deviendra pas le terminal contrôlant le processus même si celui\-ci n'est attaché à aucun autre terminal. .TP \fBO_NOFOLLOW\fP .\" 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. Si \fIpathname\fP 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 \fBO_PATH\fP dans la suite du document. .TP \fBO_NONBLOCK\fP ou \fBO_NDELAY\fP Le fichier est ouvert en mode «\ non\-bloquant\ ». Ni la fonction \fBopen\fP() 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 \fBfifo\fP(7). Pour une explication de l'effet de \fBO_NONBLOCK\fP en conjonction avec les verrouillages impératifs et les baux de fichiers, voir \fBfcntl\fP(2). .TP \fBO_PATH\fP (depuis 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 .\" 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 \fBread\fP(2), \fBwrite\fP(2), \fBfchmod\fP(2), \fBfchown\fP(2), \fBfgetxattr\fP(2), \fBmmap\fP(2)) échoueront en renvoyant l'erreur \fBEBADF\fP. Les opérations suivantes \fIpeuvent\fP être réalisées sur le descripteur de fichier obtenu\ : .RS .IP * 3 .\" commit 332a2e1244bd08b9e3ecd378028513396a004a24 .\" fstat(): commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 \fBclose\fP(2); \fBfchdir\fP(2) (à partir de Linux 3.5); \fBfstat\fP(2) (à partir de Linux 3.6). .IP * Dupliquer le descripteur de fichier (\fBdup\fP(2), \fBfcntl\fP(2), \fBF_DUPFD\fP, etc.). .IP * Consulter et affecter les valeurs des attributs du descripteur de fichier (\fBfcntl\fP(2), \fBF_GETFD\fP and \fBF_SETFD\fP). .IP * Récupérer les attributs d'état de fichiers ouverts au moyen de l'opération \fBfcntl\fP(2) \fBF_GETFL\fP\ : les attributs renvoyés comprendront le bit \fBO_PATH\fP. .IP * Transmettre le descripteur de fichier comme l'argument \fIdirfd\fP de \fBopenat\fP(2) et les autres appels système «\ *at()\ ». .IP * Transmettre le descripteur de fichier à un autre processus via une socket de domaine UNIX (consultez \fBSCM_RIGHTS\fP dans \fBunix\fP(7)). .RE .IP Lorsque \fBO_PATH\fP est précisé dans \fIflags\fP, seuls les bits \fBO_DIRECTORY\fP et \fBO_NOFOLLOW\fP de l'attribut sont pris en compte. Si \fIpathname\fP est un lien symbolique et si l'attribut \fBO_NOFOLLOW\fP 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 \fIdirfd\fP lors d'appels aux fonctions \fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2) et \fBreadlinkat\fP(2) avec un chemin d'accès vide pour permettre à l'appel de s'exécuter sur le lien symbolique. .TP \fBO_SYNC\fP 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 \fIfichier\fP (contrairement à l'exécution des opérations E/S synchrones avec garantie d'intégrité des \fIdonnées\fP fournie par \fBO_DSYNC\fP.) Au moment où \fBwrite\fP(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 à \fBwrite\fP(2) était suivi d'un appel à \fBfsync\fP(2)). \fIConsultez NOTES ci\-dessous\fP. .TP \fBO_TMPFILE\fP (depuis Linux\ 3.11) .\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e .\" commit f4e0c30c191f87851c4a53454abb55ee276f4a7e .\" commit bb458c644a59dbba3a1fe59b27106c5e68e1c4bd Créer un fichier temporaire sans nom. L’argument \fIpathname\fP 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. \fBO_TMPFILE\fP doit être indiqué avec soit \fBO_RDWR\fP, soit \fBO_WRONLY\fP, et facultativement \fBO_EXCL\fP. Si \fBO_EXCL\fP s’est pas indiqué, alors \fBlinkat\fP(2) peut être utilisé pour lier le fichier temporaire dans le système de fichier, le rendant permanent, en utilisant du code comme\ : .in +4n .nf 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); .fi .in Dans ce cas, l’argument \fImode\fP d’\fBopen\fP() détermine le mode de droits du fichier, comme avec \fBO_CREAT\fP. Indiquer \fBO_EXCL\fP en conjonction avec \fBO_TMPFILE\fP empêche de lier un fichier temporaire dans le système de fichiers comme précédemment (remarquez que la signification de \fBO_EXCL\fP dans ce cas est différente de la signification habituelle de \fBO_EXCL\fP). .\" Inspired by http://lwn.net/Articles/559147/ Les deux principaux cas d’utilisation de \fBO_TMPFILE\fP sont présentés ci\-dessous\ : .RS .IP * 3 Améliorer la fonctionnalité \fBtmpfile\fP(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. .IP * Créer un fichier initialement invisible, qui est ensuite peuplé de données et ajusté aux attributs de système de fichiers adéquats (\fBchown\fP(2), \fBchmod\fP(2), \fBfsetxattr\fP(2),\ etc.) avant d’être automatiquement lié dans le système de fichiers dans un état complètement formé (en utilisant \fBlinkat\fP(2) comme décrit précédemment). .RE .IP .\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788 .\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe \fBO_TMPFILE\fP 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. .TP \fBO_TRUNC\fP Si le fichier existe, est un fichier ordinaire et que le mode d’accès permet l’écriture (\fBO_RDWR\fP ou \fBO_WRONLY\fP), il sera tronqué à une longueur nulle. Si le fichier est une FIFO ou un périphérique terminal, l'attribut \fBO_TRUNC\fP est ignoré. Sinon, le comportement de \fBO_TRUNC\fP n'est pas précisé. Sur de nombreuses versions de Linux, il sera ignoré\ ; sur d'autres versions il déclenchera une erreur). .SS creat() \fBcreat\fP() est équivalent à \fBopen\fP() avec l'attribut \fIflags\fP égal à \fBO_CREAT | O_WRONLY | O_TRUNC\fP. .SS openat() L'appel système \fBopenat\fP() fonctionne de la même façon que \fBopen\fP(), les différences étant décrites ici. Si le chemin donné dans \fIpathname\fP est relatif, il est interprété par rapport au répertoire auquel le descripteur de fichier \fIdirfd\fP fait référence (et non par rapport au répertoire courant du processus, comme pour \fBopen\fP()). Si \fIpathname\fP est un chemin relatif, et si \fIdirfd\fP a la valeur spéciale \fBAT_FDCWD\fP, alors \fIpathname\fP est interprété par rapport au répertoire courant du processus appelant, comme dans \fBopen\fP(). Si \fIpathname\fP est un chemin absolu, \fIdirfd\fP est ignoré. .SH "VALEUR RENVOYÉE" \fBopen\fP(), \fBopenat\fP() et \fBcreat\fP() renvoient le nouveau descripteur de fichier s'ils réussissent, ou \-1 s'ils échouent, auquel cas \fIerrno\fP contient le code d'erreur. .SH ERREURS \fBopen\fP(), \fBopenat\fP() et \fBcreat\fP() peuvent échouer avec les erreurs suivantes\ : .TP \fBEACCES\fP L'accès demandé au fichier est interdit, ou la permission de parcours pour l'un des répertoires du chemin \fIpathname\fP est refusée, ou le fichier n'existe pas encore et le répertoire parent ne permet pas l'écriture. (Consultez aussi \fBpath_resolution\fP(7).) .TP \fBEDQUOT\fP Si \fBO_CREAT\fP 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. .TP \fBEEXIST\fP \fIpathname\fP existe déjà et \fBO_CREAT\fP et \fBO_EXCL\fP ont été indiqués. .TP \fBEFAULT\fP \fIpathname\fP pointe en\(hydehors de l'espace d'adressage accessible. .TP \fBEFBIG\fP Consultez \fBEOVERFLOW\fP. .TP \fBEINTR\fP Pendant qu'il était bloqué en attente de l'ouverture d'un périphérique lent (par exemple, une FIFO\ ; consultez \fBfifo\fP(7)), l'appel a été interrompu par un gestionnaire de signal\ ; consultez \fBsignal\fP(7). .TP \fBEINVAL\fP Le système de fichiers ne gère pas l’attribut \fBO_DIRECT\fP. Consultez \fBNOTES\fP pour de plus amples renseignements. .TP \fBEINVAL\fP .\" In particular, __O_TMPFILE instead of O_TMPFILE Valeur incorrecte dans \fIflags\fP. .TP \fBEINVAL\fP \fBO_TMPFILE\fP a été indiqué dans \fIflags\fP, mais ni \fBO_WRONLY\fP ni \fBO_RDWR\fP n’ont été indiqués. .TP \fBEISDIR\fP Une écriture a été demandée alors que \fIpathname\fP correspond à un répertoire (en fait, \fBO_WRONLY\fP ou \fBO_RDWR\fP ont été demandés). .TP \fBEISDIR\fP \fIpathname\fP fait référence à un répertoire existant, \fBO_TMPFILE\fP et soit \fBO_WRONLY\fP, soit \fBO_RDWR\fP, ont été indiqués dans \fIflags\fP, mais cette version du noyau ne fournit pas la fonctionnalité \fBO_TMPFILE\fP. .TP \fBELOOP\fP Trop de liens symboliques ont été rencontrés en parcourant \fIpathname\fP. .TP \fBELOOP\fP \fIpathname\fP était un lien symbolique, et \fIflags\fP indiquait \fBO_NOFOLLOW\fP mais pas \fBO_PATH\fP. .TP \fBEMFILE\fP Le processus a déjà ouvert le nombre maximal de fichiers. .TP \fBENAMETOOLONG\fP \fIpathname\fP est trop long. .TP \fBENFILE\fP La limite du nombre total de fichiers ouverts sur le système a été atteinte. .TP \fBENODEV\fP \fIpathname\fP 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, \fBENXIO\fP devrait être renvoyé.) .TP \fBENOENT\fP \fBO_CREAT\fP est absent et le fichier n'existe pas. Ou un répertoire du chemin d'accès \fIpathname\fP n'existe pas, ou est un lien symbolique pointant nulle part. .TP \fBENOENT\fP \fIpathname\fP fait référence à un répertoire inexistant, \fBO_TMPFILE\fP et soit \fBO_WRONLY\fP, soit \fBO_RDWR\fP, ont été indiqués dans \fIflags\fP, mais cette version du noyau ne fournit pas la fonctionnalité \fBO_TMPFILE\fP. .TP \fBENOMEM\fP Pas assez de mémoire pour le noyau. .TP \fBENOSPC\fP \fIpathname\fP devrait être créé mais le périphérique concerné n'a plus assez de place pour un nouveau fichier. .TP \fBENOTDIR\fP Un élément du chemin d'accès \fIpathname\fP n'est pas un répertoire, ou l'attribut \fBO_DIRECTORY\fP est utilisé et \fIpathname\fP n'est pas un répertoire. .TP \fBENXIO\fP \fBO_NONBLOCK\fP | \fBO_WRONLY\fP 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. .TP \fBEOPNOTSUPP\fP Le système de fichiers contenant \fIpathname\fP ne prend pas en charge \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 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 \fI\-D_FILE_OFFSET_BITS=64\fP essaie d'ouvrir un fichier dont la taille dépasse \fI(2<<31)\-1\fP bits\ ; consultez également \fBO_LARGEFILE\fP 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 \fBEFBIG\fP dans ce cas. .TP \fBEPERM\fP .\" Strictly speaking, it's the filesystem UID... (MTK) L'attribut \fBO_NOATIME\fP 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é (\fBCAP_FOWNER\fP). .TP \fBEROFS\fP Un accès en écriture est demandé alors que \fIpathname\fP réside sur un système de fichiers en lecture seule. .TP \fBETXTBSY\fP On a demandé une écriture alors que \fIpathname\fP correspond à un fichier exécutable actuellement utilisé. .TP \fBEWOULDBLOCK\fP L'attribut \fBO_NONBLOCK\fP est indiqué, et un bail incompatible est détenu sur le fichier (consultez \fBfcntl\fP(2)). .PP Les erreurs supplémentaires suivantes peuvent également se produire pour \fBopenat\fP()\ : .TP \fBEBADF\fP \fIdirfd\fP n'est pas un descripteur de fichier valable. .TP \fBENOTDIR\fP \fIpathname\fP est relatif, et le descripteur de fichier \fIdirfd\fP est associé à un fichier, pas à un répertoire. .SH VERSIONS \fBopenat\fP() a été ajouté au noyau Linux dans sa version 2.6.16\ ; la glibc le gère depuis la version\ 2.4. .SH CONFORMITÉ \fBopen\fP(), \fBcreat\fP()\ : SVr4, 4.3BSD, POSIX.1\-2001, POSIX.1\-2008. \fBopenat\fP()\ : POSIX.1\-2008. Les attributs \fBO_DIRECT\fP, \fBO_NOATIME\fP, \fBO_PATH\fP et \fBO_TMPFILE\fP sont spécifiques à Linux. \fB_GNU_SOURCE\fP doit être définie pour obtenir leurs définitions. Les attributs \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP et \fBO_NOFOLLOW\fP 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 \fB_POSIX_C_SOURCE\fP avec une valeur supérieure ou égale à 200809L, soit \fB_XOPEN_SOURCE\fP 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 \fB_GNU_SOURCE\fP. Comme indiqué dans \fBfeature_test_macros\fP(7), les macros de test de fonctionnalités comme \fB_POSIX_C_SOURCE\fP, \fB_XOPEN_SOURCE\fP et \fB_GNU_SOURCE\fP doivent être définies avant d'inclure \fIn’importe quel\fP fichier d'en\-tête. .SH NOTES Sous Linux, l'attribut \fBO_NONBLOCK\fP 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 \fBioctl\fP(2). .LP .\" 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 L'effet (indéfini) de \fBO_RDONLY | O_TRUNC\fP varie selon l'implémentation. Sur de nombreux systèmes, le fichier est effectivement tronqué. Notez que \fBopen\fP() peut ouvrir des fichiers spéciaux mais \fBcreat\fP() ne peut pas en créer, il faut utiliser \fBmknod\fP(2) à la place. .\" .\" Si un fichier est créé, ses horodatages \fIst_atime\fP, \fIst_ctime\fP, \fIst_mtime\fP (respectivement heure de dernier accès, de dernière modification d'état, et de dernière modification\ ; consultez \fBstat\fP(2)) sont définis à l'heure actuelle, ainsi que les champs \fIst_ctime\fP et \fIst_mtime\fP du répertoire parent. Sinon, si le fichier est modifié à cause de l'attribut \fBO_TRUNC\fP, ses champs \fIst_ctime\fP et \fIst_mtime\fP sont remplis avec l'heure actuelle. .SS "E/S synchrones" L'option POSIX\-1.2008 «\ E/S synchrones\ » décrit des variantes des E/S synchrones, ainsi que plusieurs attributs de \fBopen\fP() permettant d'en contrôler le comportement\ : \fBO_SYNC\fP, \fBO_DSYNC\fP et \fBO_RSYNC\fP. Sans chercher à savoir si une implémentation accepte cette option, elle doit au moins prendre en charge l'utilisation de \fBO_SYNC\fP pour les fichiers normaux. Linux met en oeuvre \fBO_SYNC\fP et \fBO_DSYNC\fP, mais pas \fBO_RSYNC\fP. (De façon plus ou moins correcte, glibc définit \fBO_RSYNC\fP de façon à avoir la même valeur que \fBO_SYNC\fP.) \fBO_SYNC\fP fournit l'exécution d'E/S synchrones avec garantie d'intégrité des \fIfichiers\fP, ce qui signifie que les opérations d'écriture envoient les données et les métadonnées associées au matériel. \fBO_DSYNC\fP fournit l'exécution d'E/S synchrones avec garantie d'intégrité des \fIdonnées\fP, 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 (\fIst_mtime\fP) 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, \fBO_DSYNC\fP transmettrait seulement la métadonnée relative à la longueur du fichier (quand \fBO_SYNC\fP y ajouterait l'horodatage de dernière modification). Avant Linux 2.6.33, Linux mettait seulement en oeuvre l'attribut \fBO_SYNC\fP de \fBopen\fP(). 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 \fIdonnées\fP (autrement dit, \fBO_SYNC\fP était de fait mis en oeuvre comme \fBO_DSYNC\fP). .\" .\" A partir de Linux 2.6.33, une véritable prise de charge de \fBO_SYNC\fP est fournie. Cependant, pour assurer la compatibilité ascendante binaire, \fBO_DSYNC\fP a été défini avec la même valeur que le \fBO_SYNC\fP «\ historique\ », et \fBO_SYNC\fP a été défini comme un nouvel attribut (de deux bits) qui comprend l'attribut \fBO_DSYNC\fP. Ceci permet d'assurer que les applications compilées avec les nouveaux en\-têtes auront au moins la sémantique de \fBO_DSYNC\fP sur les noyaux antérieurs à 2.6.33. .SS NFS Plusieurs problèmes se posent avec le protocole NFS, concernant entre autres \fBO_SYNC\fP, et \fBO_NDELAY\fP. .\" .\" Sur les systèmes de fichiers NFS, où la correspondance d'UID est activée, \fBopen\fP() peut renvoyer un descripteur de fichier alors qu'une requête \fBread\fP(2) par exemple sera refusée avec le code d'erreur \fBEACCES\fP. En effet, le client a effectué \fBopen\fP() 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. .SS "mode accès au fichier" Contrairement aux autres valeurs qui peuvent être indiquées dans \fIflags\fP, les valeurs du \fImode d'accès\fP \fBO_RDONLY\fP, \fBO_WRONLY\fP et \fBO_RDWR\fP ne sont pas des bits individuels. Ils définissent l'ordre des deux bits de poids faible de \fIflags\fP, et ont pour valeur respective 0, 1 et 2. En d'autres termes, l'association \fBO_RDONLY | O_WRONLY\fP est une erreur logique et n'a certainement pas la même signification que \fBO_RDWR\fP. .\" 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 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 \fBioctl\fP(2) propres aux périphériques. .SS "Justification des appels openat() et des APIs des descripteurs de fichier de répertoires" \fBopenat\fP() 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, \fBfaccessat\fP(2), \fBfanotify_mark\fP(2), \fBfchmodat\fP(2), \fBfchownat\fP(2), \fBfstatat\fP(2), \fBfutimesat\fP(2), \fBlinkat\fP(2), \fBmkdirat\fP(2), \fBmknodat\fP(2), \fBname_to_handle_at\fP(2), \fBreadlinkat\fP(2), \fBrenameat\fP(2), \fBsymlinkat\fP(2), \fBunlinkat\fP(2), \fButimensat\fP(2), \fBmkfifoat\fP(3) et \fBscandirat\fP(3)) sont pris en charge pour deux raisons. L'explication est ici donnée dans le contexte de l'appel \fBopenat\fP(), mais des arguments analogues sont valables pour les autres interfaces. Tout d'abord, \fBopenat\fP() permet à une application d'éviter les problèmes d'accès concurrents lors de l'utilisation de \fBopen\fP() 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é à \fBopen\fP() peut être modifié parallèlement à l'appel \fBopen\fP(). 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 \fIdirfd\fP de \fBopenat\fP(). .\" .\" Enfin, \fBopenat\fP() 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 \fI/proc/self/fd/\fPdirfd, mais de façon moins efficace. .SS O_DIRECT .LP L'attribut \fBO_DIRECT\fP 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 \fBXFS_IOC_DIOINFO\fP de \fBxfsctl\fP(3). .LP 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. .LP Les E/S \fBO_DIRECT\fP ne devraient jamais être exécutées en même temps que l'appel système \fBfork\fP(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 \fBMAP_PRIVATE\fP de \fBmmap\fP(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 \fBfork\fP(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 \fBO_DIRECT\fP a été créé en utilisant \fBshmat\fP(2) ou \fBmmap\fP(2) avec l'attribut \fBMAP_SHARED\fP. Cette restriction ne s'applique pas non plus quand le tampon mémoire a été configuré comme \fBMADV_DONTFORK\fP avec \fBmadvise\fP(2), en s'assurant qu'il ne sera pas disponible au fils après \fBfork\fP(2). .LP L'attribut \fBO_DIRECT\fP a été introduit par SGI IRIX, qui a des restrictions d'alignement identiques à Linux 2.4. IRIX a aussi un appel \fBfcntl\fP(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. .LP La gestion de \fBO_DIRECT\fP 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 \fBopen\fP() échouera avec l'erreur \fBEINVAL\fP s'il a été utilisé. .LP Les applications devraient éviter de mélanger des entrées\-sorties \fBO_DIRECT\fP 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 \fBmmap\fP(2) et d'entrées\-sorties directes pour les mêmes fichiers. .LP Le comportement de \fBO_DIRECT\fP 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 \fBO_DIRECT\fP 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 \fBO_DIRECT\fP. 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 \fBO_DIRECT\fP. .PP En résumé, \fBO_DIRECT\fP est un outil potentiellement puissant qui doit être utilisé avec précaution. Les applications devraient utiliser \fBO_DIRECT\fP comme une option pour améliorer les performances, qui devrait être désactivée par défaut. .PP .RS «\ 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.\ » \(em Linus. .RE .SH BOGUES .\" FIXME . Check bugzilla report on open(O_ASYNC) .\" See http://bugzilla.kernel.org/show_bug.cgi?id=5993 Actuellement, il n'est pas possible d'activer les entrées\-sorties contrôlées par les signaux en indiquant \fBO_ASYNC\fP lors de l'appel \fBopen\fP()\ ; il faut utiliser \fBfcntl\fP(2) pour activer cet attribut. Deux codes d’erreur différents –\ \fBEISDIR\fP et \fBENOENT\fP\ — doivent être vérifiés pour essayer de déterminer si le noyau prend en charge la fonctionnalité \fBO_TMPFILE\fP. .SH "VOIR AUSSI" \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_name_at\fP(2), \fBread\fP(2), \fBsocket\fP(2), \fBstat\fP(2), \fBumask\fP(2), \fBunlink\fP(2), \fBwrite\fP(2), \fBfopen\fP(3), \fBfifo\fP(7), \fBpath_resolution\fP(7), \fBsymlink\fP(7) .SH COLOPHON Cette page fait partie de la publication 3.65 du projet \fIman\-pages\fP 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/. .SH TRADUCTION Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a par l'équipe de traduction francophone au sein du projet perkamon . .PP Christophe Blaess (1996-2003), Alain Portal (2003-2006). Julien Cristau et l'équipe francophone de traduction de Debian\ (2006-2009). .PP Veuillez signaler toute erreur de traduction en écrivant à ou par un rapport de bogue sur le paquet \fBmanpages\-fr\fR. .PP Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande «\ \fBman\ \-L C\fR \fI
\fR\ \fI\fR\ ».