.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson; .\" and Copyright (C) 1998 Jamie Lokier; .\" and Copyright (C) 2002-2010, 2014 Michael Kerrisk; .\" and Copyright (C) 2014 Jeff Layton .\" and Copyright (C) 2014 David Herrmann .\" and Copyright (C) 2017 Jens Axboe .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified 1993-07-24 by Rik Faith .\" Modified 1995-09-26 by Andries Brouwer .\" and again on 960413 and 980804 and 981223. .\" Modified 1998-12-11 by Jamie Lokier .\" Applied correction by Christian Ehrhardt - aeb, 990712 .\" Modified 2002-04-23 by Michael Kerrisk .\" Added note on F_SETFL and O_DIRECT .\" Complete rewrite + expansion of material on file locking .\" Incorporated description of F_NOTIFY, drawing on .\" Stephen Rothwell's notes in Documentation/dnotify.txt. .\" Added description of F_SETLEASE and F_GETLEASE .\" Corrected and polished, aeb, 020527. .\" Modified 2004-03-03 by Michael Kerrisk .\" Modified description of file leases: fixed some errors of detail .\" Replaced the term "lease contestant" by "lease breaker" .\" Modified, 27 May 2004, Michael Kerrisk .\" Added notes on capability requirements .\" Modified 2004-12-08, added O_NOATIME after note from Martin Pool .\" 2004-12-10, mtk, noted F_GETOWN bug after suggestion from aeb. .\" 2005-04-08 Jamie Lokier , mtk .\" Described behavior of F_SETOWN/F_SETSIG in .\" multithreaded processes, and generally cleaned .\" up the discussion of F_SETOWN. .\" 2005-05-20, Johannes Nicolai , .\" mtk: Noted F_SETOWN bug for socket file descriptor in Linux 2.4 .\" and earlier. Added text on permissions required to send signal. .\" 2009-09-30, Michael Kerrisk .\" Note obsolete F_SETOWN behavior with threads. .\" Document F_SETOWN_EX and F_GETOWN_EX .\" 2010-06-17, Michael Kerrisk .\" Document F_SETPIPE_SZ and F_GETPIPE_SZ. .\" 2014-07-08, David Herrmann .\" Document F_ADD_SEALS and F_GET_SEALS .\" 2017-06-26, Jens Axboe .\" Document F_{GET,SET}_RW_HINT and F_{GET,SET}_FILE_RW_HINT .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH fcntl 2 "30 mars 2023" "Pages du manuel de Linux 6.05.01" .SH NOM fcntl \- Manipuler un descripteur de fichier .SH BIBLIOTHÈQUE Bibliothèque C standard (\fIlibc\fP, \fI\-lc\fP) .SH SYNOPSIS .nf \fB#include \fP .PP \fBint fcntl(int \fP\fIfd\fP\fB, int \fP\fIcmd\fP\fB, ... /* \fP\fIarg\fP\fB */ );\fP .fi .SH DESCRIPTION \fBfcntl\fP() permet de se livrer à diverses opérations sur le descripteur de fichier \fIfd\fP. L'opération en question est déterminée par la valeur de l'argument \fIcmd\fP. .PP \fBfcntl\fP() accepte un troisième paramètre optionnel. La nécessité de fournir, ou pas, ce paramètre dépend de \fIcmd\fP. Le paramètre doit être du type indiqué entre parenthèses après chaque nom de commande \fIcmd\fP (dans la plupart des cas, le type requis est un \fIint\fP, et le paramètre est identifié en utilisant le nom \fIarg\fP), ou \fIvoid\fP est indiqué si le paramètre n'est pas nécessaire. .PP Certaines des opérations suivantes ne sont prises en charge qu’à partir d’une version donnée du noyau Linux. La méthode préférée pour vérifier si le noyau hôte prend en charge une certaine opération est d’invoquer \fBfcntl\fP() avec la valeur de \fIcmd\fP voulue et ensuite de tester si l’appel a échoué avec \fBEINVAL\fP, indiquant que le noyau ne reconnaît pas cette valeur. .SS "Dupliquer un descripteur de fichier" .TP \fBF_DUPFD\fP (\fIint\fP) Dupliquer le descripteur de fichier \fIfd\fP en utilisant le plus petit numéro de descripteur de fichier libre supérieur ou égal à \fIarg\fP. Cela est différent de \fBdup2\fP(2), qui utilise exactement le descripteur de fichier transmis. .IP En cas de réussite, le nouveau descripteur de fichier est renvoyé. .IP Consultez \fBdup\fP(2) pour plus d'informations. .TP \fBF_DUPFD_CLOEXEC\fP (\fIint\fP\ ; depuis Linux 2.6.24) Comme pour \fBF_DUPFD\fP, mais positionner en plus l'attribut «\ close\-on\-exec\ » pour le descripteur de fichier dupliqué. Indiquer cet attribut permet à un programme d'éviter une opération \fBF_SETFD\fP de \fBfcntl\fP() supplémentaire pour positionner l'attribut \fBFD_CLOEXEC\fP. Pour une explication sur ce en quoi cet attribut est utile, consultez la description de \fBO_CLOEXEC\fP dans \fBopen\fP(2). .SS "Attributs du descripteur de fichier" Les commandes suivantes manipulent les attributs associés à un descripteur de fichier. Actuellement, un seul attribut est défini\ : il s'agit de \fBFD_CLOEXEC\fP, l'attribut «\ close\(hyon\(hyexec\ ». Si le bit \fBFD_CLOEXEC\fP est positionné, le descripteur de fichier sera automatiquement fermé lors d'un \fBexecve\fP(2) réussi (si \fBexecve\fP(2) échoue, le descripteur de fichier reste ouvert). Si le bit \fBFD_CLOEXEC\fP n'est pas positionné, le descripteur de fichier restera ouvert à la fin d’un \fBexecve\fP(2). .TP \fBF_GETFD\fP (\fIvoid\fP) Renvoyer (en tant que résultat de la fonction) les attributs du descripteur de fichier\ ; \fIarg\fP est ignoré. .TP \fBF_SETFD\fP (\fIint\fP) Positionner les attributs du descripteur de fichier avec la valeur précisée par \fIarg\fP. .PP Dans un programme multithreadé, l'utilisation simultanée dans un thread de \fBfcntl\fP() avec \fBF_SETFD\fP afin de définir l'attribut «\ close\-on\-exec\ » (\fBFD_CLOEXEC\fP), et de \fBfork\fP(2) suivi de \fBexecve\fP(2) dans un autre thread rend le programme vulnérable à une condition de concurrence pouvant provoquer la divulgation du descripteur de fichier dans le programme exécuté dans le processus enfant. Consultez les détails de l'attribut \fBO_CLOEXEC\fP dans \fBopen\fP(2) qui décrivent une solution à ce problème. .SS "Attribut d'état du fichier" .\" or .\" .BR creat (2), Un descripteur de fichier dispose de certains attributs d’état, initialisés par \fBopen\fP(2) et éventuellement modifiés par \fBfcntl\fP(). Les descripteurs de fichier dupliqués (obtenus avec \fBdup\fP(2), \fBfcntl\fP(F_DUPFD), \fBfork\fP(2),\ etc.) concernent la même description de fichier ouvert, et par conséquent partagent les mêmes attributs d’état de fichier. .PP Les attributs et leurs sémantiques sont décrits dans la page \fBopen\fP(2). .TP \fBF_GETFL\fP (\fIvoid\fP) Renvoyer (en tant que résultat de la fonction) les droits d'accès du fichier et les drapeaux d'état du fichier\ ; \fIarg\fP est ignoré. .TP \fBF_SETFL\fP (\fIint\fP) Positionner les drapeaux d'état du fichier à la valeur indiquée par \fIarg\fP. Les drapeaux des droits d'accès au fichier (\fBO_RDONLY\fP, \fBO_WRONLY\fP, \fBO_RDWR\fP) et les attributs de création du fichier (\fBO_CREAT\fP, \fBO_EXCL\fP, \fBO_NOCTTY\fP, \fBO_TRUNC\fP) de \fIarg\fP sont ignorés. Sous Linux, cette commande ne peut changer que les attributs \fBO_APPEND\fP, \fBO_ASYNC\fP, \fBO_DIRECT\fP, \fBO_NOATIME\fP et \fBO_NONBLOCK\fP. Modifier les attributs \fBO_DSYNC\fP et \fBO_SYNC\fP est impossible, consultez \fBBOGUES\fP ci\-dessous. .SS "Verrouillages d’enregistrements coopératifs" Linux implémente les verrouillages d’enregistrements UNIX traditionnels («\ associés au processus\ »), tels que normalisés par POSIX. Pour une alternative spécifique à Linux avec de meilleures sémantiques, consultez la discussion suivante sur les verrouillages de description de fichier ouvert. .PP \fBF_SETLK\fP, \fBF_SETLKW\fP et \fBF_GETLK\fP servent à gérer les verrouillages d'enregistrements (d’intervalle d’octets, de segments de fichiers ou de zones de fichiers). Le troisième argument, \fIlock\fP, est un pointeur sur une structure qui a au moins les champs suivants (dans un ordre non indiqué). .PP .in +4n .EX struct flock { ... short l_type; /* Type de verrouillage\ : F_RDLCK, F_WRLCK, F_UNLCK */ short l_whence; /* Interprétation de l_start: SEEK_SET, SEEK_CUR, SEEK_END */ off_t l_start; /* Décalage de début du verrouillage */ off_t l_len; /* Nombre d'octets du verrouillage */ pid_t l_pid; /* PID du processus bloquant notre verrou (mis par F_GETLK et F_OFD_GETLK seulement) */ ... }; .EE .in .PP Les champs \fIl_whence\fP, \fIl_start\fP et \fIl_len\fP de cette structure indiquent l'intervalle d'octets à verrouiller. Des octets après la fin du fichier peuvent être verrouillés, mais pas des octets avant le début du fichier. .PP \fIl_start\fP est la position de début du verrou, et est interprété de façon relative\ : au début du fichier (si \fIl_whence\fP vaut \fBSEEK_SET\fP)\ ; à la position actuelle dans le fichier (si \fIl_whence\fP vaut \fBSEEK_CUR\fP)\ ; à la fin du fichier (si \fIl_whence\fP vaut \fBSEEK_END\fP). Dans les deux derniers cas, \fIl_start\fP peut être un nombre négatif, à partir du moment où la position fournie ne pointe pas avant le début du fichier. .PP \fIl_len\fP indique le nombre d'octets à verrouiller. Si \fIl_len\fP est positif, alors l'intervalle à verrouiller couvre les octets à partir de \fIl_start\fP jusqu'à \fIl_start\fP+\fIl_len\fP\-1 (inclus). Indiquer \fB0\fP dans \fIl_len\fP a une signification particulière\ : cela verrouille tous les octets à partir de la position indiquée par \fIl_whence\fP et \fIl_start\fP jusqu'à la fin du fichier, quelle que soit la taille que prendra le fichier. .PP POSIX.1\-2001 permet (mais n'impose pas) à une implémentation de prendre en charge des valeurs de \fIl_len\fP négatives\ ; si \fIl_len\fP est négatif, l'intervalle décrivant le verrou \fIlock\fP couvre les octets \fIl_start\fP+\fIl_len\fP jusqu'à \fIl_start\fP\-1 inclus. Cela est géré par Linux\ 2.4.21 et Linux\ 2.5.49. .PP Le champ \fIl_type\fP peut servir à placer un verrou en lecture (\fBF_RDLCK\fP) ou en écriture (\fBF_WRLCK\fP) sur un fichier. Un nombre quelconque de processus peuvent tenir un verrou en lecture (partagé), sur une zone d'un fichier, mais un seul peut avoir un verrou en écriture (exclusif). Un verrou en écriture exclut tous les autres verrous, aussi bien en lecture qu'en écriture. Un processus donné ne peut tenir qu'un seul verrou sur une zone d'un fichier\ ; si un nouveau verrou est appliqué sur une zone déjà verrouillée, alors le verrou précédent est converti suivant le nouveau type. Ces conversions pourraient entraîner le découpage, la réduction ou l'extension du verrou existant si le nombre d'octets du nouveau verrou ne coïncide pas exactement avec celui de l'ancien. .TP \fBF_SETLK\fP (\fIstruct flock *\fP) Acquérir (si \fIl_type\fP vaut \fBF_RDLCK\fP ou \fBF_WRLCK\fP) ou libérer (si \fIl_type\fP vaut \fBF_UNLCK\fP) le verrou sur les octets indiqués par les champs \fIl_whence\fP, \fIl_start\fP, et \fIl_len\fP de \fIlock\fP. Si un conflit avec un verrou tenu par un autre processus existe, cet appel renvoie \fB\-1\fP et positionne \fIerrno\fP aux valeurs \fBEACCES\fP ou \fBEAGAIN\fP (l’erreur renvoyée dans ce cas dépend des implémentations, donc POSIX impose aux applications portables de vérifier les deux erreurs). .TP \fBF_SETLKW\fP (\fIstruct flock *\fP) Comme \fBF_SETLK\fP, mais attendre la libération du verrou au lieu de renvoyer une erreur si un verrou en conflit est utilisé sur le fichier. Si un signal est reçu pendant l'attente, l'appel est interrompu et renverra immédiatement (après le retour du gestionnaire de signaux) la valeur \fB\-1\fP. \fIerrno\fP sera remplie avec la valeur \fBEINTR\fP\ ; consultez \fBsignal\fP(7). .TP \fBF_GETLK\fP (\fIstruct flock *\fP) En entrée dans cette routine, \fIlock\fP décrit un verrou que nous aimerions placer sur le fichier. Si le verrouillage est possible, \fBfcntl\fP() ne le fait pas, mais renvoie \fBF_UNLCK\fP dans le champ \fIl_type\fP de \fIlock\fP et laisse les autres champs de la structure inchangés. .IP Si un ou plusieurs verrouillages incompatibles empêchaient l'action, alors \fBfcntl\fP() renvoie des informations sur l'un de ces verrous dans les champs \fIl_type\fP, \fIl_whence\fP, \fIl_start\fP, et \fIl_len\fP de \fIlock\fP. Si le verrouillage en conflit est un verrouillage d’enregistrements UNIX traditionnels («\ associé au processus\ »), alors le champ \fIl_pid\fP est défini avec le PID du processus détenant ce verrou. Si le verrouillage en conflit est un verrouillage de description de fichier ouvert, alors \fIl_pid\fP est défini à \fB\-1\fP. Remarquez que les renseignements renvoyés pourraient déjà être périmés au moment ou l’appelant les inspecte. .PP Pour pouvoir placer un verrou en lecture, \fIfd\fP doit être ouvert au moins en lecture. Pour placer un verrou en écriture, \fIfd\fP doit être ouvert en écriture. Pour placer les deux types de verrous, il faut une ouverture en lecture/écriture. .PP Lors du placement de verrous avec \fBF_SETLKW\fP, le noyau détecte les interblocages (\fIdeadlocks\fP), au moyen desquels au moins deux processus ont leurs demandes de verrouillage réciproquement bloquées par des verrous détenus par d’autres processus. Par exemple, supposons qu’un processus A détient un verrou d’écriture sur l’octet 100 d’un fichier et qu’un processus B détient un verrou d’écriture sur l’octet 200. Si les deux processus tentent alors de verrouiller l’octet déjà verrouillé par l’autre processus en utilisant \fBF_SETLKW\fP, alors, sans détection d’interblocage, les deux processus resteront bloqués indéfiniment. Quand le noyau détecte ce type d’interblocages, il force l’une des demandes bloquantes de verrouillage à échouer immédiatement avec l’erreur \fBEDEADLK\fP\ ; une application qui rencontre ce type d’erreur devrait libérer certains de ses verrous pour permettre à d’autres applications de continuer avant de tenter d’obtenir de nouveau les verrous dont elle a besoin. Les interblocages circulaires, impliquant plus de deux processus, sont également détectés. Remarquez, cependant, que l’algorithme de détection d’interblocages du noyau a ses limites, consultez \fBBOGUES\fP. .PP Outre la suppression par un \fBF_UNLCK\fP explicite, les verrous sont automatiquement libérés lorsque le processus se termine. .PP Les verrouillages d'enregistrements ne sont pas hérités par les enfants lors d'un \fBfork\fP(2), mais sont conservés à la fin d'un \fBexecve\fP(2). .PP À cause des tampons gérés par la bibliothèque \fBstdio\fP(3), l'utilisation des verrous d'enregistrements avec les routines de celle\(hyci est déconseillée. Utilisez plutôt \fBread\fP(2) et \fBwrite\fP(2). .PP Les verrouillages d'enregistrements décrits précédemment sont associés au processus (contrairement aux verrouillages de description de fichier ouvert décrits ci\-dessous). Cela a quelques conséquences malheureuses. .IP \- 3 .\" (Additional file descriptors referring to the same file .\" may have been obtained by calls to .\" .BR open "(2), " dup "(2), " dup2 "(2), or " fcntl ().) Si le processus ferme \fIl'un\fP des descripteurs se référant à un fichier, alors tous les verrous du processus sur ce fichier sont libérés, quels que soient le ou les descripteurs de fichier sur lesquels les verrous avaient été obtenus. C'est dangereux\ : cela signifie qu'un processus peut perdre ses verrous sur un fichier comme \fI/etc/passwd\fP ou \fI/etc/mtab\fP si, pour une raison quelconque, une fonction de bibliothèque décide d’ouvrir, lire, puis refermer le même fichier. .IP \- Les threads d’un processus partagent les verrous. Autrement dit, un programme multithreadé ne pas pas utiliser de verrouillage d’enregistrement pour s’assurer que les threads ne vont pas accéder simultanément à la même zone d’un fichier. .PP Les verrouillages de description de fichier ouvert apportent une solution à ces deux problèmes. .SS "Verrouillages de description de fichier ouvert (non POSIX)" .\" FIXME . Review progress into POSIX .\" http://austingroupbugs.net/view.php?id=768 Les verrouillages de description de fichier ouvert sont des verrouillages d’intervalle d’octets coopératifs dont le fonctionnement est identique en presque tout point aux verrouillages d’enregistrements traditionnels décrits précédemment. Ce type de verrouillage est spécifique à Linux et disponible depuis la version\ 3.15. Pour une explication des descriptions de fichier ouvert, consultez \fBopen\fP(2). .PP La principale différence entre les deux types de verrouillage est que les verrouillages d’enregistrements traditionnels sont associés à un processus, alors que les verrouillages de description de fichier ouvert sont associés à la description de fichier ouvert sur laquelle ils sont obtenus, tout comme les verrous obtenus avec \fBflock\fP(2). Par conséquent (et contrairement aux verrouillages d’enregistrements coopératifs traditionnels), les verrouillages de description de fichier ouvert sont hérités entre \fBfork\fP(2) (et \fBclone\fP(2) avec \fBCLONE_FILES\fP) et ne sont automatiquement libérés que lors de la dernière fermeture de la description de fichier ouvert, au lieu d’être libérés lors de n’importe quelle fermeture du fichier. .PP Les combinaisons de verrouillage de conflit (à savoir un verrouillage en lecture et en écriture, ou deux verrouillages en écriture), où l'un est un verrouillage de description de fichier ouvert, et l'autre un verrouillage traditionnel d'enregistrement sont toujours en conflit même lorsqu'ils sont acquis par le même processus sur le même descripteur de fichier. .PP Les verrouillages de description de fichier ouvert placés à l’aide de la même description de fichier ouvert (c’est\-à\-dire à l’aide du même descripteur de fichier ou à l’aide d’un descripteur de fichier dupliqué par \fBfork\fP(2), \fBdup\fP(2), \fBfcntl\fP(2) \fBF_DUPFD\fP,\ etc.) sont toujours compatibles\ : si un nouveau verrou est placé sur une zone déjà verrouillée, alors le verrou existant est converti suivant le nouveau (ces conversions pourraient avoir pour conséquence le découpage, la réduction ou l'extension du verrou existant comme évoqué précédemment). .PP En revanche, les verrouillages de description de fichier ouvert peuvent être en conflit entre eux quand ils sont obtenus à l’aide de descriptions de fichier ouvert différentes. Ainsi, les threads dans un programme multithreadé peuvent utiliser des verrouillages de description de fichier ouvert pour synchroniser l’accès à une zone de fichier si tous les threads réalisent leur propre appel d’\fBopen\fP(2) sur le fichier et utilisent les verrouillages à l’aide du descripteur de fichier qui en résulte. .PP Comme avec les verrouillages coopératifs traditionnels, le troisième argument de \fBfcntl\fP(), \fIlock\fP, est un pointeur vers une structure \fIflock\fP. Contrairement aux verrouillages d’enregistrements traditionnels, le champ \fIl_pid\fP de cette structure doit être mis à zéro lors de l’utilisation des commandes décrites ci\-dessous. .PP Les commandes permettant d’interagir avec les verrouillages de description de fichier ouvert sont similaires à celles utilisées avec les verrouillages traditionnels. .TP \fBF_OFD_SETLK\fP (\fIstruct flock *\fP) Acquérir (si \fIl_type\fP vaut \fBF_RDLCK\fP ou \fBF_WRLCK\fP) ou libérer (si \fIl_type\fP vaut \fBF_UNLCK\fP) un verrou de description de fichier ouvert sur les octets indiqués par les champs \fIl_whence\fP, \fIl_start\fP et \fIl_len\fP de \fIlock\fP. Si un conflit avec un verrou détenu par un autre processus existe, cet appel renvoie \fB\-1\fP et définit \fIerrno\fP à \fBEAGAIN\fP. .TP \fBF_OFD_SETLKW\fP (\fIstruct flock *\fP) Comme \fBF_OFD_SETLK\fP, mais si un verrou en conflit existe sur le fichier attendre la libération du verrou. Si un signal à intercepter est reçu pendant l'attente, l'appel est interrompu et renverra immédiatement (après renvoi du gestionnaire de signaux) la valeur \fB\-1\fP et \fIerrno\fP sera définie à \fBEINTR\fP\ ; consultez \fBsignal\fP(7). .TP \fBF_OFD_GETLK\fP (\fIstruct flock *\fP) En entrée dans cette routine, \fIlock\fP décrit un verrou de description de fichier ouvert que nous aimerions placer sur le fichier. Si le verrouillage est possible, \fBfcntl\fP() ne le fait pas, mais renvoie \fBF_UNLCK\fP dans le champ \fIl_type\fP de \fIlock\fP et laisse les autres champs de la structure inchangés. Si un ou plusieurs verrouillages incompatibles empêchaient l'action, alors des informations sur l'un de ces verrous sont renvoyés à l’aide de \fIlock\fP, comme décrit précédemment pour \fBF_GETLK\fP. .PP .\" commit 57b65325fe34ec4c917bc4e555144b4a94d9e1f7 .\" Dans l’implémentation actuelle, aucune détection d’interblocage n’est réalisée pour les verrouillages de description de fichier ouvert (contrairement aux verrouillages d’enregistrements associés au processus, pour lesquels le noyau réalise une détection d’interblocage). .SS "Verrouillage impératif" \fIAttention\fP\ : l'implémentation Linux du verrouillage obligatoire n'est pas fiable. Voir BOGUES ci\-dessous. À cause de ces bogues et du fait que cette fonction soit vue comme peu utilisée, depuis Linux 4.5, le verrouillage obligatoire est devenu une fonction facultative gérée par une option de configuration (\fBCONFIG_MANDATORY_FILE_LOCKING\fP). Cette fonctionnalité n'est plus prise en charge depuis Linux 5.15 et supérieur. .PP Par défaut, à la fois les verrouillages d’enregistrements traditionnels (associés au processus) et ceux de description de fichier ouvert sont coopératifs. Les verrouillages coopératifs ne sont pas imposés, donc ils ne fonctionnent qu'entre processus qui les utilisent. .PP Les deux types de verrouillages peuvent aussi être impératifs. Les verrous impératifs sont appliqués à tous les processus. Si un processus tente d'effectuer un accès incompatible (par exemple \fBread\fP(2) ou \fBwrite\fP(2)) sur une zone d'un fichier qui a un verrou impératif, le résultat dépend de l'attribut \fBO_NONBLOCK\fP du descripteur de fichier. S'il n'est pas activé, l'appel système est bloqué jusqu'à ce que le verrou soit enlevé ou converti en un mode compatible avec l'accès demandé. Si l'attribut \fBO_NONBLOCK\fP est activé, l'appel système échoue avec l'erreur \fBEAGAIN\fP. .PP Pour utiliser des verrous impératifs, ce type de verrouillage doit être activé sur le système de fichiers contenant le fichier à verrouiller (en utilisant l'option «\ \fI\-o\ mand\fP\ » de \fBmount\fP(8)), ou l'attribut \fBMS_MANDLOCK\fP de \fBmount\fP(2). Le verrouillage impératif est activé pour un fichier en désactivant la permission d'exécution du groupe et en activant le bit de permission Set\-GID (consultez \fBchmod\fP(1) et \fBchmod\fP(2)). .PP .\" Le verrouillage impératif n’est pas défini par POSIX. Certains autres systèmes permettent également d’utiliser le verrouillage impératif, mais la façon de l’activer dépend des systèmes. .SS "Verrouillages perdus" Quand un verrou d'observation est obtenu sur un système de fichiers en réseau comme NFS, il est possible que le verrou soit perdu. Cela peut arriver suite à une action d'administration sur le serveur ou à une partition du réseau (à savoir une perte de la connexion réseau avec le serveur) qui dure assez pour que le serveur pense que le client ne fonctionne plus. .PP .\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d Quand un système de fichiers détermine qu'un verrou est perdu, les futures requêtes \fBread\fP(2) ou \fBwrite\fP(2) peuvent échouer avec l'erreur \fBEIO\fP. Cette erreur persistera jusqu'à la suppression du verrou ou la fermeture du descripteur de fichier. Depuis Linux 3.12, cela se produit au moins sur NFSv4 (y compris toutes les versions mineures). .PP .\" Certaines versions d'UNIX envoient un signal (\fBSIGLOST\fP) dans ce cas. Linux ne définit pas ce signal et il ne fournit pas de notification asynchrone de perte de verrous. .SS "Gestion des signaux" \fBF_GETOWN\fP, \fBF_SETOWN\fP, \fBF_GETOWN_EX\fP, \fBF_SETOWN_EX\fP, \fBF_GETSIG\fP et \fBF_SETSIG\fP servent à gérer les signaux de disponibilité d'entrée\-sortie\ : .TP \fBF_GETOWN\fP (\fIvoid\fP) Renvoyer (comme résultat de la fonction) le PID ou l'ID de processus qui reçoit les signaux \fBSIGIO\fP et \fBSIGURG\fP pour les événements concernant le descripteur de fichier \fIfd\fP. Les ID de processus sont renvoyés sous forme de valeurs positives\ ; les ID de groupe de processus sont renvoyés sous forme de valeurs négatives (mais consultez la section BOGUES ci\(hydessous). \fIarg\fP est ignoré. .TP \fBF_SETOWN\fP (\fIint\fP) Définir le PID ou l'identifiant de processus qui recevront les signaux \fBSIGIO\fP et \fBSIGURG\fP pour les événements concernant le descripteur \fIfd\fP. L'ID de processus ou de groupe de processus cible est indiqué dans \fIarg\fP. L'ID d'un processus est indiqué sous forme d'une valeur positive\ ; l'ID d'un groupe de processus est formulé en tant que valeur négative. En général, le processus appelant indique son propre PID comme argument (\fIarg\fP est donc \fBgetpid\fP(2)). .IP Outre la définition du propriétaire du descripteur de fichier, vous pourriez aussi activer la génération de signaux sur le descripteur de fichier. Cela se fait en utilisant la commande \fBF_SETFL\fP de \fBfcntl\fP() pour positionner le drapeau d'état du fichier \fBO_ASYNC\fP sur le descripteur de fichier. Par conséquent, un signal \fBSIGIO\fP est envoyé dès que l'entrée ou la sortie sont possibles sur ce descripteur. La commande \fBF_SETSIG\fP de \fBfcntl\fP() peut être utilisée pour recevoir un autre signal que \fBSIGIO\fP. .IP L'envoi d'un signal au processus (ou groupe de processus) propriétaire indiqué par \fBF_SETOWN\fP est conditionné par les mêmes vérifications de permissions que l'envoi d'un signal par \fBkill\fP(2), où le processus envoyant le signal est celui qui utilise \fBF_SETOWN\fP (mais consultez la section BOGUES ci\(hydessous). Si cette vérification échoue, le signal est ignoré silencieusement. \fINote\fP\ : l'opération \fBF_SETOWN\fP enregistre les droits de l'appelant utilisés lors de l'appel \fBfcntl\fP() pour les vérifications de permissions. .IP .\" The following appears to be rubbish. It doesn't seem to .\" be true according to the kernel source, and I can write .\" a program that gets a terminal-generated SIGIO even though .\" it is not the foreground process group of the terminal. .\" -- MTK, 8 Apr 05 .\" .\" If the file descriptor .\" .I fd .\" refers to a terminal device, then SIGIO .\" signals are sent to the foreground process group of the terminal. Si le descripteur \fIfd\fP est un socket, \fBF_SETOWN\fP permet également la réception de signaux \fBSIGURG\fP lorsque des données hors\(hybande arrivent sur le socket. (\fBSIGURG\fP est émis dans toutes les situations où l'appel \fBselect\fP(2) aurait indiqué que le socket est dans une «\ situation exceptionnelle\ ».) .IP Le paragraphe ci\-dessous était pertinent Linux\ 2.6.x, jusqu'à Linux\ 2.6.11 inclus\ : .RS .IP .\" The relevant place in the (2.6) kernel source is the .\" 'switch' in fs/fcntl.c::send_sigio_to_task() -- MTK, Apr 2005 .\" send_sigurg()/send_sigurg_to_task() bypasses .\" kill_fasync()/send_sigio()/send_sigio_to_task() .\" to directly call send_group_sig_info() .\" -- MTK, Apr 2005 (kernel 2.6.11) Si une valeur non nulle est passée à \fBF_SETSIG\fP dans un processus multithreadé utilisant une bibliothèque de threads gérant les groupes de threads (par exemple NPTL), une valeur positive passée à \fBF_SETOWN\fP a une signification différente\ : au lieu d'être un PID identifiant tout un processus, il s'agit d'un identifiant de thread, référant à un thread spécifique dans un processus. Par conséquent, il peut être nécessaire de passer à \fBF_SETOWN\fP la valeur renvoyée par \fBgettid\fP(2) plutôt que celle renvoyée par \fBgetpid\fP(2) pour obtenir les résultats souhaités si \fBF_SETSIG\fP est utilisé. (Dans les implémentations actuelles des threads sous Linux, l'identifiant de thread (TID) du thread principal est son identifiant de processus. Cela signifie qu'un processus avec un seul thread peut utiliser indifféremment \fBgettid\fP(2) ou \fBgetpid\fP(2).) Veuillez toutefois noter que les remarques de ce paragraphe ne s'appliquent pas au signal \fBSIGURG\fP généré lorsque des données hors\(hybande sont disponibles sur un socket\ : ce signal est toujours envoyé soit à un processus, soit à un groupe de processus, selon la valeur donnée à \fBF_SETOWN\fP. .RE .IP Le comportement ci\-dessus a été supprimé par accident dans Linux 2.6.12, et ne sera pas remis. À partir de Linux 2.6.32, utilisez \fBF_SETOWN_EX\fP pour envoyer les signaux \fBSIGIO\fP et \fBSIGURG\fP à un thread en particulier. .TP \fBF_GETOWN_EX\fP (\fIstruct f_owner_ex *\fP) (depuis Linux 2.6.32) Renvoyer les paramètres du propriétaire du descripteur de fichier actuel, tels que définis par une utilisation antérieure de \fBF_SETOWN_EX\fP. L'information est renvoyée dans la structure pointée par \fIarg\fP, qui a la forme suivante\ : .IP .in +4n .EX struct f_owner_ex { int type; pid_t pid; }; .EE .in .IP Le champ \fItype\fP aura l'une des valeurs \fBF_OWNER_TID\fP, \fBF_OWNER_PID\fP ou \fBF_OWNER_PGRP\fP. Le champ \fIpid\fP est un entier positif représentant un identifiant de thread, de processus ou de groupe de processus. Consultez \fBF_SETOWN_EX\fP pour plus de détails. .TP \fBF_SETOWN_EX\fP (\fIstruct f_owner_ex *\fP) (depuis Linux 2.6.32) Cette opération effectue une tâche similaire à \fBF_SETOWN\fP. Elle autorise l'appelant à diriger les signaux de disponibilité d'entrées\-sorties vers un thread, un processus ou un groupe de processus spécifiques. L'appellant indique le destinataire des signaux avec \fIarg\fP, qui est un pointeur vers une structure \fIf_owner_ex\fP. Le champ \fItype\fP possède l'une des valeurs suivantes, qui définit comment \fIpid\fP est interprété\ : .RS .TP \fBF_OWNER_TID\fP Envoyer le signal au thread dont l'identifiant (la valeur renvoyée par un appel à \fBclone\fP(2) ou \fBgettid\fP(2)) est indiqué par \fIpid\fP. .TP \fBF_OWNER_PID\fP Envoyer le signal au processus dont l'identifiant est indiqué par \fIpid\fP. .TP \fBF_OWNER_PGRP\fP Envoyer le signal au groupe de processus dont l'identifiant est indiqué par \fIpid\fP. Notez que, à la différence de \fBF_SETOWN\fP, un identifiant de groupe de processus est indiqué ici avec une valeur positive. .RE .TP \fBF_GETSIG\fP (\fIvoid\fP) Renvoyer (comme résultat de la fonction) le numéro du signal émis lorsque l'entrée ou la sortie deviennent possibles. Une valeur nulle signifie l'émission de \fBSIGIO\fP. Toute autre valeur (y compris \fBSIGIO\fP) précise le signal émis, et des informations supplémentaires seront disponibles pour le gestionnaire s'il est installé avec \fBSA_SIGINFO\fP. \fIarg\fP est ignoré. .TP \fBF_SETSIG\fP (\fIint\fP) .\" .\" The following was true only up until Linux 2.6.11: .\" .\" Additionally, passing a nonzero value to .\" .B F_SETSIG .\" changes the signal recipient from a whole process to a specific thread .\" within a process. .\" See the description of .\" .B F_SETOWN .\" for more details. Définir le signal à émettre lorsque l'entrée ou la sortie deviennent possibles à la valeur fournie par \fIarg\fP. Une valeur nulle signifie l'émission de \fBSIGIO\fP. Toute autre valeur (y compris \fBSIGIO\fP) précise le signal à émettre, et des informations supplémentaires seront disponibles pour le gestionnaire s'il est installé avec \fBSA_SIGINFO\fP. .IP En utilisant \fBF_SETSIG\fP avec une valeur non nulle, et en configurant \fBSA_SIGINFO\fP pour le gestionnaire (consultez \fBsigaction\fP(2)), des informations supplémentaires sur les événements d'entrées\-sorties sont fournies au gestionnaire à travers une structure \fIsiginfo_t\fP. Si le champ \fIsi_code\fP indique que la source est \fBSI_SIGIO\fP, le champ \fIsi_fd\fP fournit le descripteur du fichier concerné par l'événement. Sinon, il n'y a pas d'indication de descripteurs de fichier en attente, et il faut utiliser les mécanismes habituels (\fBselect\fP(2), \fBpoll\fP(2), \fBread\fP(2) avec \fBO_NONBLOCK\fP configuré,\ etc.) pour déterminer quels descripteurs de fichier sont disponibles pour les entrées\-sorties. .IP Remarquez que le descripteur de fichier fourni dans \fIsi_fd\fP est celui indiqué lors de l'opération \fBF_SETSIG\fP. Cela peut provoquer un effet de bord inhabituel. Si le descripteur de fichier est dupliqué (\fBdup\fP(2) ou équivalent), et si le descripteur de fichier d'origine est fermé, alors des événements E/S continueront à être émis mais le champ \fIsi_fd\fP contiendra le numéro du descripteur de fichier à présent fermé. .IP En sélectionnant un signal temps réel (valeur >= \fBSIGRTMIN\fP), de multiples événements d'entrées\-sorties peuvent être mémorisés avec le même numéro (la mémorisation dépend de la mémoire disponible). Des informations supplémentaires sont disponibles, comme ci\(hydessus, si \fBSA_SIGINFO\fP est configuré pour le gestionnaire. .IP .\" See fs/fcntl.c::send_sigio_to_task() (2.4/2.6) sources -- MTK, Apr 05 Notez que Linux impose une limite sur le nombre de signaux temps réel qui peuvent être mis en attente pour un processus (consultez \fBgetrlimit\fP(2) et \fBsignal\fP(7)), et si cette limite est atteinte, le noyau change de comportement et envoie \fBSIGIO\fP, et ce signal est délivré au processus entier plutôt qu'au thread spécifique. .PP En utilisant ces mécanismes, un programme peut implémenter des entrées\-sorties totalement asynchrones, la plupart du temps sans avoir besoin d'invoquer \fBselect\fP(2) ou \fBpoll\fP(2). .PP L'utilisation de \fBO_ASYNC\fP est spécifique à BSD et Linux. La seule utilisation de \fBF_GETOWN\fP et \fBF_SETOWN\fP spécifiée dans POSIX.1 est en conjonction avec l’utilisation du signal \fBSIGURG\fP sur les sockets (POSIX ne spécifie pas le signal \fBSIGIO\fP). \fBF_GETOWN_EX\fP, \fBF_SETOWN_EX\fP, \fBF_GETSIG\fP et \fBF_SETSIG\fP sont spécifiques à Linux. POSIX dispose d'entrées\-sorties asynchrones et de la structure \fIaio_sigevent\fP pour effectuer la même chose. Cela est également disponible sous Linux dans la bibliothèque GNU C (glibc). .SS Baux \fBF_SETLEASE\fP et \fBF_GETLEASE\fP (depuis Linux 2.4) servent respectivement à établir un nouveau bail et à consulter le bail actuel sur le descripteur de fichier indiqué par \fIfd\fP. (NdT\ : je traduis «\ lease\ » par «\ bail\ », faute de terme plus technique.) Le bail sur un fichier fournit un mécanisme par lequel un processus détenteur du bail est averti (par délivrance d'un signal) lorsqu'un autre processus (le «\ casseur de bail\ ») essaie d'appeler \fBopen\fP(2) ou \fBtruncate\fP(2) sur le fichier vers lequel pointe ce descripteur de fichier. .TP \fBF_SETLEASE\fP (\fIint\fP) Définir ou supprimer un bail de fichier en fonction de la valeur fournie dans l'entier \fIarg\fP\ : .RS .TP \fBF_RDLCK\fP .\" The following became true in Linux 2.6.10: .\" See the man-pages-2.09 Changelog for further info. Prendre un bail en lecture. Le processus appelant sera prévenu lorsqu'un autre processus ouvrira le fichier en écriture ou le tronquera. Un bail en lecture ne peut être placé que sur un descripteur de fichier ouvert en lecture seule. .TP \fBF_WRLCK\fP Prendre un bail en écriture. Le processus appelant sera prévenu lorsqu'un autre processus ouvrira le fichier (en lecture ou écriture) ou le tronquera. Un bail en écriture ne peut être pris sur le fichier que s'il n'y a aucun autre descripteur de fichier ouvert pour le fichier. .TP \fBF_UNLCK\fP Supprimer le bail sur un fichier. .RE .PP Les baux sont associés à une description de fichier ouvert (consultez \fBopen\fP(2)). Cela signifie que les descripteurs de fichier dupliqués (créés par, par exemple, \fBfork\fP(2) ou \fBdup\fP(2)) font référence au même bail, et que ce bail peut être modifié ou résilié par n'importe lequel de ces descripteurs. De plus, le bail est résilié soit par une opération \fBF_UNLCK\fP explicite sur n'importe lequel de ces descripteurs dupliqués, soit lorsque tous ces descripteurs ont été fermés. .PP Les baux ne peuvent être pris que sur des fichiers normaux. Un processus non privilégié ne peut prendre un bail que sur un fichier dont l'UID (le propriétaire) correspond au FS\-UID du processus. Un processus possédant la capacité \fBCAP_LEASE\fP peut prendre un bail sur n'importe quel fichier. .TP \fBF_GETLEASE\fP (\fIvoid\fP) Indiquer le type de bail possédé sur le descripteur de fichier \fIfd\fP en renvoyant \fBF_RDLCK\fP, \fBF_WRLCK\fP, ou \fBF_UNLCK\fP, signifiant respectivement que le processus appelant a un bail en lecture, écriture, ou pas de bail sur le fichier. \fIarg\fP est ignoré. .PP Lorsqu'un processus (le «\ casseur de bail\ ») appelle \fBopen\fP(2) ou \fBtruncate\fP(2) en conflit avec un bail établi par \fBF_SETLEASE\fP, l'appel système est bloqué par le noyau et le noyau avertit le processus tenant le bail par l'envoi d'un signal (\fBSIGIO\fP par défaut). Le tenant du bail doit répondre à ce signal en effectuant tout le nettoyage nécessaire pour que le fichier soit accessible par un autre processus (par exemple en vidant des tampons internes) et en supprimant ou déclassant son bail. Un bail est supprimé en appelant la commande \fBF_SETLEASE\fP avec \fIarg\fP valant \fBF_UNLCK\fP. Si le tenant du bail possède un bail en écriture sur le fichier et que le casseur de bail ouvre le fichier en lecture, il est suffisant que le tenant du bail déclasse le bail en un bail en lecture. Cela est effectué en appelant la commande \fBF_SETLEASE\fP avec \fIarg\fP valant \fBF_RDLCK\fP. .PP Si le détenteur du bail n'arrive pas à le déclasser ou le supprimer avant le nombre de secondes indiqué dans \fI/proc/sys/fs/lease\-break\-time\fP alors le noyau supprimera ou déclassera de force le bail du processus qui le détient. .PP Dès qu'un cassage de bail a été commencé, \fBF_GETLEASE\fP renvoie le type de bail cible (\fBF_RDLCK\fP ou \fBF_UNLCK\fP, en fonction de ce qui serait compatible avec le casseur de bail) jusqu'à ce que le détenteur du bail ne le déclasse ou le supprime volontairement, ou que le noyau ne soit forcé à le faire après expiration du délai de cassage de bail. .PP Dès que le bail a été, de gré ou de force, résilié ou déclassé et en supposant que le casseur de bail n'a pas débloqué son appel système, le noyau permet à ce dernier de se dérouler. .PP Si l'appel à \fBopen\fP(2) ou \fBtruncate\fP(2) du casseur de bail est interrompu par un gestionnaire de signal, l'appel système échoue avec l'erreur \fBEINTR\fP, mais les autres étapes décrites ci\(hydessous se déroulent normalement. Si le casseur de bail est tué par un signal pendant que son appel système \fBopen\fP(2) ou \fBtruncate\fP(2) bloque, tout se déroule comme décrit ci\(hydessus. De même, si le casseur de bail utilise l'option \fBO_NONBLOCK\fP de \fBopen\fP(2), l'appel retourne immédiatement avec l'erreur \fBEWOULDBLOCK\fP, mais les autres étapes se déroulent comme décrit ci\(hydessus. .PP Le signal de notification par défaut pour le tenant du bail est \fBSIGIO\fP, mais on peut le modifier avec la commande \fBF_SETSIG\fP de la fonction \fBfcntl\fP(). Si une commande \fBF_SETSIG\fP est réalisée (même pour \fBSIGIO\fP), et si le gestionnaire de signal est installé avec \fBSA_SIGINFO\fP, alors il recevra une structure \fIsiginfo_t\fP en second argument, et le champ \fIsi_fd\fP contiendra le descripteur de fichier du bail où il y a eu une tentative d'accès par un autre processus. (Cela sert si le processus tient des baux sur plusieurs fichiers.) .SS "Notification de modification de fichier et de répertoire (dnotify)" .TP \fBF_NOTIFY\fP (\fIint\fP) (Depuis Linux 2.4) Fournir un avertissement lorsque le répertoire correspondant à \fIfd\fP ou l'un des fichiers qu'il contient est modifié. Les événements à notifier sont précisés dans \fIarg\fP, sous forme de masque regroupant par un OU binaire zéro, une ou plusieurs des constantes suivantes\ : .PP .RS .PD 0 .TP \fBDN_ACCESS\fP Accès à un fichier (\fBread\fP(2), \fBpread\fP(2), \fBreadv\fP(2) et similaires) .TP \fBDN_MODIFY\fP Modification d'un fichier (\fBwrite\fP(2), \fBpwrite\fP(2), \fBwritev\fP(2), \fBtruncate\fP(2), \fBftruncate\fP(2) et similaires). .TP \fBDN_CREATE\fP Création d'un fichier (\fBopen\fP(2), \fBcreat\fP(2), \fBmknod\fP(2), \fBmkdir\fP(2), \fBlink\fP(2), \fBsymlink\fP(2), \fBrename\fP(2) dans ce répertoire). .TP \fBDN_DELETE\fP Suppression d'un fichier (\fBunlink\fP(2), \fBrename\fP(2) dans un autre répertoire, \fBrmdir\fP(2)). .TP \fBDN_RENAME\fP Un fichier a été renommé dans le même répertoire (\fBrename\fP(2)). .TP \fBDN_ATTRIB\fP Les attributs d'un fichier ont été modifiés (\fBchown\fP(2), \fBchmod\fP(2), \fButime\fP(2), \fButimensat\fP(2) et similaires). .PD .RE .IP (Afin d'obtenir ces définitions, la macro \fB_GNU_SOURCE\fP doit être définie avant d'inclure \fItout\fP fichier d'en\(hytête). .IP Les notifications de répertoire sont habituellement uniques, et l'application doit réenregistrer une demande pour les notifications ultérieures. Inversement, si \fBDN_MULTISHOT\fP est incluse dans \fIarg\fP, les notifications resteront en effet jusqu'à une demande explicite de suppression. .IP .\" The following does seem a poor API-design choice... Une série de \fBF_NOTIFY\fP sont cumulés, les événements décrits dans \fIarg\fP étant ajoutés à l'ensemble des événements déjà surveillés. Pour supprimer les notifications de tous les événements, il faut invoquer \fBF_NOTIFY\fP avec \fIarg\fP valant \fB0\fP. .IP La notification se produit par l'occurrence d'un signal. Le signal par défaut est \fBSIGIO\fP, mais on peut le changer avec la commande \fBF_SETSIG\fP de \fBfcntl\fP() (remarquez que \fBSIGIO\fP est un des signaux standards sans file d’attente\ ; basculer vers l’utilisation d’un signal temps réel signifie que plusieurs notifications peuvent être mises en attente dans le processus). Dans ce cas, le gestionnaire de signal reçoit une structure \fIsiginfo_t\fP en second argument (si le gestionnaire a été installé avec \fBSA_SIGINFO\fP) dont le champ \fIsi_fd\fP contient le descripteur du fichier qui a déclenché la notification (utile pour superviser plusieurs répertoires). .IP En outre, avec \fBDN_MULTISHOT\fP, un signal temps réel devrait être utilisé pour la notification pour pouvoir empiler les notifications successives. .IP \fBRemarque\fP\ : les nouvelles applications devraient utiliser l'interface \fIinotify\fP (disponible depuis Linux\ 2.6.13), qui fournit une bien meilleure interface pour obtenir des notifications d'événements sur le système de fichiers. Consultez \fBinotify\fP(7). .SS "Changer la capacité d'un tube" .TP \fBF_SETPIPE_SZ\fP (\fIint\fP\ ; depuis Linux 2.6.35) Changer la capacité du tube référencé par \fIfd\fP pour contenir au moins \fIarg\fP octets. Un processus non privilégié peut ajuster la capacité d'un tube à toute valeur comprise entre la taille de page du système et la limite définie dans \fI/proc/sys/fs/pipe\-max\-size\fP (consultez \fBproc\fP(5)). Les tentatives pour définir la capacité du tube en dessous de la taille de page sont silencieusement arrondies à la taille de page. Les tentatives d'un processus non privilégié pour définir la capacité du tube au dessus de \fI/proc/sys/fs/pipe\-max\-size\fP renvoie l'erreur \fBEPERM\fP\ ; un processus privilégié (\fBCAP_SYS_RESOURCE\fP) peut passer outre cette limite. .IP Lors de l'affectation d'un tampon à un tube, le noyau peut utiliser une capacité supérieure à \fIarg\fP, si c'est plus pratique pour l'implémentation (dans l'implémentation actuelle, l'affectation se fait sur le prochain multiple de la taille de la page supérieur à la puissance de deux de la taille indiquée). La capacité actuelle (en octets) définie est renvoyée en tant que résultat de la fonction. .IP Essayer de définir une capacité de tube plus petite que la taille de l'espace du tampon actuellement utilisé pour stocker des données aboutit à l'erreur \fBEBUSY\fP. .IP Remarquez qu'à cause de la manière dont les pages du tampon du tube sont utilisées quand des données sont écrites dans le tube, le nombre d'octets qui peuvent être écrits peut être inférieur à la taille nominale, selon la taille des écritures. .TP \fBF_GETPIPE_SZ\fP (\fIvoid\fP\ ; depuis Linux 2.6.35) .\" Renvoyer (comme résultat de la fonction) la capacité du tube référencé par \fIfd\fP. .SS "Verrouillages de fichier" Les verrous de fichier limitent le jeu d'opérations autorisées sur un fichier donné. Pour chaque verrou positionné sur un fichier, un ensemble spécifique d'opérations échouera sur le fichier avec \fBEPERM\fP à partir de maintenant. Le fichier est dit verrouillé (sealed). Le jeu de verrous dépend du type de fichier et du système de fichiers sous\-jacents. Pour un aperçu du verrouillage de fichiers, un point sur ses objectifs et des exemples de code, voir \fBmemfd_create\fP(2). .PP Actuellement, les verrous de fichier ne peuvent être appliqués que sur un descripteur de fichier renvoyé par \fBmemfd_create\fP(2) (si \fBMFD_ALLOW_SEALING\fP est utilisé). Sur d'autres systèmes de fichiers, toutes les opérations de \fBfcntl\fP() agissant sur les verrous renverront \fBEINVAL\fP. .PP Les verrous constituent une propriété d'un inœud. Ainsi, tous les descripteurs de fichier ouverts qui se rapportent au même inœud partagent le même jeu de verrous. En outre, les verrous ne peuvent jamais être supprimés mais uniquement ajoutés. .TP \fBF_ADD_SEALS\fP (\fIint\fP\ ; depuis Linux 3.17) Ajouter les verrous donnés dans le paramètre \fIarg\fP du masque de bit à l'ensemble de verrous de l'inœud auquel se rapporte le descripteur de fichier \fIfd\fP. Les verrous ne peuvent pas être supprimés de nouveau. Une fois que cet appel réussit, ils sont renforcés immédiatement par le noyau. Si le jeu de verrous actuel comprend \fBF_SEAL_SEAL\fP (voir ci\-dessous), cet appel sera rejeté avec \fBEPERM\fP. L'ajout d'un verrou déjà défini n'est pas opérationnel, si \fBF_SEAL_SEAL\fP n'est pas déjà positionné. Pour positionner un verrou, le descripteur de fichier \fIfd\fP doit être accessible en écriture. .TP \fBF_GET_SEALS\fP (\fIvoid\fP\ ; depuis Linux 3.17) Renvoyer (en tant que résultat de la fonction) le jeu de verrous actuel de l'inœud auquel se rapporte \fIfd\fP. Si aucun verrou n'est positionné, \fB0\fP est renvoyé. Si le fichier ne gère pas les verrous, \fB\-1\fP est renvoyé et \fIerrno\fP est positionné sur \fBEINVAL\fP. .PP Les verrous suivants sont disponibles\ : .TP \fBF_SEAL_SEAL\fP Si ce verrou est positionné, tout appel suivant à \fBfcntl\fP() avec \fBF_ADD_SEALS\fP échouera avec l'erreur \fBEPERM\fP. Ce verrou empêche donc toute modification du jeu de verrous lui\-même. Si le jeu de verrous initial du fichier comprend \fBF_SEAL_SEAL\fP, cela le rend en fait constant et verrouillé. .TP \fBF_SEAL_SHRINK\fP Si ce verrou est positionné, le fichier en question ne peut pas voir sa taille réduite. Cela concerne \fBopen\fP(2) avec le drapeau \fBO_TRUNC\fP ainsi que \fBtruncate\fP(2) et \fBftruncate\fP(2). Ces appels échouent avec \fBEPERM\fP si vous essayez de réduire le fichier en question. Augmenter la taille reste possible. .TP \fBF_SEAL_GROW\fP Si ce verrou est positionné, le fichier en question ne peut pas voir sa taille augmentée. Cela concerne \fBwrite\fP(2) après la fin du fichier, \fBtruncate\fP(2), \fBftruncate\fP(2) et \fBfallocate\fP(2). Ces appels échoueront avec \fBEPERM\fP si vous les utilisez pour augmenter la taille du fichier. Si vous la laissez stable ou la réduisez, ces appels fonctionneront comme prévu. .TP \fBF_SEAL_WRITE\fP .\" One or more other seals are typically used with F_SEAL_WRITE .\" because, given a file with the F_SEAL_WRITE seal set, then, .\" while it would no longer be possible to (say) write zeros into .\" the last 100 bytes of a file, it would still be possible .\" to (say) shrink the file by 100 bytes using ftruncate(), and .\" then increase the file size by 100 bytes, which would have .\" the effect of replacing the last hundred bytes by zeros. .\" Si ce verrou est positionné, vous ne pouvez pas modifier le contenu du fichier. Remarquez que la réduction ou l'augmentation de la taille du fichier restent possibles et autorisées. Ainsi, ce verrou s'utilise en principe avec un autre verrou. Il concerne \fBwrite\fP(2) et \fBfallocate\fP(2) (combiné au drapeau \fBFALLOC_FL_PUNCH_HOLE\fP). Ces appels échoueront avec \fBEPERM\fP si ce verrou est positionné. De plus, les tentatives de créer de nouveaux tableaux de mémoire (memory\-mappings) accessibles en écriture avec \fBmmap\fP(2) échoueront également avec \fBEPERM\fP. .IP L'utilisation de l'opération \fBF_ADD_SEALS\fP pour définir le verrou \fBF_SEAL_WRITE\fP échoue avec \fBEBUSY\fP si un tableau partagé accessible en écriture existe. De tels tableaux doivent être désassociés avant d'ajouter ce verrou. De plus, s'il existe des opérations d'E/S asynchrones (\fBio_submit\fP(2)) en attente sur le fichier, toutes les écritures postérieures seront ignorées. .TP \fBF_SEAL_FUTURE_WRITE\fP (depuis Linux 5.1) L'effet de ce verrou est identique à \fBF_SEAL_WRITE\fP, mais le contenu du fichier peut encore être modifié avec des tableaux partagés accessibles en écriture créés avant que le verrou ne soit positionné. Toute tentative de créer de nouveaux tableaux accessibles en écriture sur le fichier avec \fBmmap\fP(2) échouera avec \fBEPERM\fP. De même, une tentative d'écriture dans le fichier avec \fBwrite\fP(2) échouera avec \fBEPERM\fP. .IP .\" En utilisant ce verrou, un processus peut créer un tampon de mémoire qu'il peut continuer à modifier tout en le partageant sur une base de «\ lecture seule\ » avec d'autres processus. .SS "Indications de lecture/écriture de fichiers" Les indications (hints) de durée d’écriture peuvent être utilisées pour informer le noyau de la durée relative prévue des écritures sur un inœud ou à l’aide d’une description de fichier ouvert en particulier (voir \fBopen\fP(2) pour une explication sur les descriptions de fichier ouvert). Dans ce contexte, le terme «\ durée d'écriture\ » (write lifetime) signifie la durée prévue de vie des données sur le média avant d'être remplacées ou écrasées. .PP Une application peut utiliser les différentes valeurs de référence indiquées ci\-dessous pour séparer les écritures en différentes classes, pour que plusieurs utilisateurs ou applications fonctionnant sur un seul dorsal de stockage puissent agréger leurs motifs E/S de manière cohérente. Cependant, il n'existe pas de sémantique fonctionnelle impliquée par ces attributs et plusieurs classes E/S peuvent utiliser les valeurs de référence de durée d'écriture de manière arbitraire, tant que celles\-ci sont utilisées de manière cohérente. .PP Les opérations suivantes peuvent être appliquées au descripteur de fichier, \fIfd\fP\ : .TP \fBF_GET_RW_HINT\fP (\fIuint64_t *\fP\ ; depuis Linux 4.13) Renvoie la valeur de référence («\ hint\ ») de lecture/écriture associée à l'inœud sous\-jacent auquel renvoie \fIfd\fP. .TP \fBF_SET_RW_HINT\fP (\fIuint64_t *\fP\ ; depuis Linux 4.13) Définit la valeur de référence de lecture/écriture associée à l'inœud sous\-jacent auquel renvoie \fIfd\fP. Cette valeur de référence persiste soit jusqu'à être explicitement modifiée, soit jusqu'à ce que le système de fichiers sous\-jacent ne soit démonté. .TP \fBF_GET_FILE_RW_HINT\fP (\fIuint64_t *\fP\ ; depuis Linux 4.13) Renvoie la valeur de référence «\ hint\ » de lecture/écriture associée à la description de fichier ouvert à laquelle renvoie \fIfd\fP. .TP \fBF_SET_FILE_RW_HINT\fP (\fIuint64_t *\fP\ ; depuis Linux 4.13) Définit la valeur de référence de lecture/écriture associée à la description de fichier ouvert à laquelle se rapporte \fIfd\fP. .PP Si une description de fichier ouvert n'a pas de valeur de référence de lecture/écriture assignée, elle devra utiliser la valeur affectée à l'inœud s'il y en a une. .PP Les valeurs de référence de lecture/écriture suivantes sont applicables depuis Linux 4.13\ : .TP \fBRWH_WRITE_LIFE_NOT_SET\fP Aucune valeur de référence en particulier n'a été définie. Il s'agit de la valeur par défaut. .TP \fBRWH_WRITE_LIFE_NONE\fP Aucune durée de vie spécifique à l'écriture n'a été associée à ce fichier ou à cet inœud. .TP \fBRWH_WRITE_LIFE_SHORT\fP Les données écrites dans cet inœud ou via cette description de fichier ouvert doivent avoir une durée de vie courte. .TP \fBRWH_WRITE_LIFE_MEDIUM\fP Les données écrites dans cet inœud ou via cette description de fichier ouvert doivent avoir une durée de vie supérieure à celle des données écrites avec \fBRWH_WRITE_LIFE_SHORT\fP. .TP \fBRWH_WRITE_LIFE_LONG\fP Les données écrites dans cet inœud ou via cette description de fichier ouvert doivent avoir une durée de vie supérieure à celle des données écrites avec \fBRWH_WRITE_LIFE_MEDIUM\fP. .TP \fBRWH_WRITE_LIFE_EXTREME\fP Les données écrites dans cet inœud ou via cette description de fichier ouvert doivent avoir une durée de vie supérieure à celle des données écrites avec \fBRWH_WRITE_LIFE_LONG\fP. .PP Toutes les valeurs de référence spécifiques à l'écriture sont relatives entre elles et aucun sens absolu individuel ne devrait leur être attribué. .SH "VALEUR RENVOYÉE" Pour qu'un appel réussisse, le code de retour dépend de l'opération\ : .TP \fBF_DUPFD\fP Le nouveau descripteur de fichier. .TP \fBF_GETFD\fP Valeur des attributs du descripteur de fichier. .TP \fBF_GETFL\fP Valeur des attributs d'état du fichier. .TP \fBF_GETLEASE\fP Le type de bail tenu sur le descripteur de fichier. .TP \fBF_GETOWN\fP Valeur du propriétaire du descripteur de fichier. .TP \fBF_GETSIG\fP La valeur du signal envoyé lorsque la lecture ou l'écriture deviennent possibles, ou zéro pour le comportement \fBSIGIO\fP traditionnel. .TP \fBF_GETPIPE_SZ\fP, \fBF_SETPIPE_SZ\fP La capacité du tube. .TP \fBF_GET_SEALS\fP Un masque de bit identifiant les verrous positionnés sur le inœud auquel renvoie \fIfd\fP. .TP Toutes les autres commandes\ : Zéro. .PP En cas d'erreur, la valeur de retour est \fB\-1\fP et \fIerrno\fP est définie pour préciser l'erreur. .SH ERREURS .TP \fBEACCES\fP ou \fBEAGAIN\fP L'opération est interdite en raison de verrous tenus par d'autres processus. .TP \fBEAGAIN\fP L'opération est impossible à cause d'une projection en mémoire effectuée par un autre processus. .TP \fBEBADF\fP \fIfd\fP n'est pas un descripteur de fichier ouvert .TP \fBEBADF\fP \fIfd\fP vaut \fBF_SETLK\fP ou \fBF_SETLKW\fP et les droits d'ouverture sur le descripteur de fichier ne correspondent pas au type de verrou demandé. .TP \fBEBUSY\fP \fIcmd\fP vaut \fBF_SETPIPE_SZ\fP et la capacité du nouveau tube indiqué dans \fIarg\fP est inférieure à la taille de l'espace du tampon actuellement utilisé pour stocker les données dans le tube. .TP \fBEBUSY\fP \fIcmd\fP vaut \fBF_ADD_SEALS\fP, \fIarg\fP inclut \fBF_SEAL_WRITE\fP et il existe un tableau partagé accessible en écriture sur le fichier auquel se rapporte \fIfd\fP. .TP \fBEDEADLK\fP Le verrouillage \fBF_SETLKW\fP conduirait à un interblocage. .TP \fBEFAULT\fP \fIlock\fP se trouve en dehors de l'espace d'adressage. .TP \fBEINTR\fP \fIcmd\fP vaut \fBF_SETLKW\fP ou \fBF_OFD_SETLKW\fP et l'opération a été interrompue par un signal\ ; voir \fBsignal\fP(7). .TP \fBEINTR\fP \fIcmd\fP vaut \fBF_GETLK\fP, \fBF_SETLK\fP, \fBF_OFD_GETLK\fP ou \fBF_OFD_SETLK\fP et l'opération a été interrompue par un signal avant la vérification ou l'acquisition du verrouillage. Généralement, quand on verrouille un fichier distant (comme un verrou sur NFS), mais cela peut aussi arriver localement. .TP \fBEINVAL\fP La valeur indiquée dans \fIcmd\fP n'est pas reconnue par ce noyau. .TP \fBEINVAL\fP \fIcmd\fP vaut \fBF_ADD_SEALS\fP et \fIarg\fP inclut un bit de verrou non reconnu. .TP \fBEINVAL\fP \fIcmd\fP vaut \fBF_ADD_SEALS\fP ou \fBF_GET_SEALS\fP et le système de fichiers contenant l'inœud auquel se rapporte \fIfd\fP ne prend pas en charge les verrous. .TP \fBEINVAL\fP \fIcmd\fP vaut \fBF_DUPFD\fP et \fIarg\fP est négatif ou supérieur à la valeur maximale permise (voir le point sur \fBRLIMIT_NOFILE\fP dans \fBgetrlimit\fP(2)). .TP \fBEINVAL\fP \fIcmd\fP vaut \fBF_SETSIG\fP et \fIarg\fP n'est pas un numéro de signal autorisé. .TP \fBEINVAL\fP \fIcmd\fP est \fBF_OFD_SETLK\fP, \fBF_OFD_SETLKW\fP ou \fBF_OFD_GETLK\fP, et \fIl_pid\fP n’a pas été défini comme nul. .TP \fBEMFILE\fP \fIcmd\fP vaut \fBF_DUPFD\fP et la limite par processus du nombre de descripteurs de fichier ouverts a été atteinte. .TP \fBENOLCK\fP Trop de verrous sont ouverts, ou la table des verrous est pleine, ou le verrouillage distant (par exemple par NFS) a échoué. .TP \fBENOTDIR\fP \fBF_NOTIFY\fP a été indiqué dans \fIcmd\fP, mais \fIfd\fP ne fait pas référence à un répertoire. .TP \fBEPERM\fP \fIcmd\fP vaut \fBF_SETPIPE_SZ\fP et la limite rigide ou souple du tube de l'utilisateur a été atteinte\ ; voir \fBpipe\fP(7). .TP \fBEPERM\fP Essai d'effacement de l'attribut \fBO_APPEND\fP sur un fichier, mais il est considéré comme en\-ajout\-seulement. .TP \fBEPERM\fP \fIcmd\fP valait \fBF_ADD_SEALS\fP, mais \fIfd\fP n'était pas ouvert en écriture ou le jeu de verrous actuel sur le fichier inclut déjà \fBF_SEAL_SEAL\fP. .SH STANDARDS POSIX.1\-2008. .PP .\" .PP .\" SVr4 documents additional EIO, ENOLINK and EOVERFLOW error conditions. \fBF_GETOWN_EX\fP, \fBF_SETOWN_EX\fP, \fBF_SETPIPE_SZ\fP, \fBF_GETPIPE_SZ\fP, \fBF_GETSIG\fP, \fBF_SETSIG\fP, \fBF_NOTIFY\fP, \fBF_GETLEASE\fP et \fBF_SETLEASE\fP sont spécifiques à Linux. (Définissez la macro \fB_GNU_SOURCE\fP pour avoir ces définitions). .PP \fBF_OFD_SETLK\fP, \fBF_OFD_SETLKW\fP et \fBF_OFD_GETLK\fP sont spécifiques à Linux (et il faut définir \fB_GNU_SOURCE\fP pour obtenir leurs définitions), mais le travail est en cours pour les avoir dans la prochaine version de POSIX.1. .PP .\" FIXME . Once glibc adds support, add a note about FTM requirements \fBF_ADD_SEALS\fP et \fBF_GET_SEALS\fP sont spécifiques à Linux. .SH HISTORIQUE SVr4, 4.3BSD, POSIX.1\-2001. .PP Seules les opérations \fBF_DUPFD\fP, \fBF_GETFD\fP, \fBF_SETFD\fP, \fBF_GETFL\fP, \fBF_SETFL\fP, \fBF_GETLK\fP, \fBF_SETLK\fP et \fBF_SETLKW\fP sont spécifiées dans POSIX.1\-2001. .PP .\" .BR _BSD_SOURCE , .\" or \fBF_GETOWN\fP et \fBF_SETOWN\fP sont spécifiées dans POSIX.1\-2001 (pour activer ces définitions, vous devez définir soit \fB_XOPEN_SOURCE\fP à la valeur supérieure ou égale à 500, soit \fB_POSIX_C_SOURCE\fP à la valeur supérieure ou égale à 200809L). .PP \fBF_DUPFD_CLOEXEC\fP est spécifiée dans POSIX.1\-2008 (pour activer cette définition, vous devez définir \fB_POSIX_C_SOURCE\fP avec une valeur supérieure ou égale à 200809L, ou \fB_XOPEN_SOURCE\fP avec une valeur supérieure ou égale à 700). .SH NOTES .\" Les erreurs renvoyées par \fBdup2\fP(2) ne sont pas les mêmes que celles renvoyées par \fBF_DUPFD\fP. .SS "Verrouillages de fichier" .\" L'appel système \fBfcntl\fP() originel de Linux n'a pas été conçu pour gérer les positions (dans la structure \fIflock\fP) dans des fichiers de très grosse taille. En conséquence, Linux\ 2.4 a ajouté l'appel système \fBfcntl64\fP(). Ce nouvel appel système utilise une structure différente de verrouillage de fichier, \fIflock64\fP, ainsi que les commandes correspondantes \fBF_GETLK64\fP, \fBF_SETLK64\fP et \fBF_SETLKW64\fP. Cependant, ces détails peuvent être ignorés par les applications qui utilisent la glibc, car sa fonction \fBfcntl\fP() encapsule de manière transparente l'appel système le plus récent disponible. .SS "Verrouillages d’enregistrements" Depuis Linux\ 2.0, il n'y a pas d'interaction entre les types de verrous placés par \fBflock\fP(2) et \fBfcntl\fP(). .PP .\" e.g., Solaris 8 documents this field in fcntl(2), and Irix 6.5 .\" documents it in fcntl(5). mtk, May 2007 .\" Also, FreeBSD documents it (Apr 2014). Plusieurs systèmes ont d'autres champs dans \fIstruct flock\fP comme, par exemple, \fIl_sysid\fP (pour identifier la machine où se trouve le verrou). Clairement, \fIl_pid\fP seul ne sera pas très utile si le processus détenant le verrou s'exécute sur une autre machine\ ; sur Linux, bien que ce champ soit présent sur certaines architectures (comme MIPS32), ce champ n'est pas utilisé. .PP L'appel système \fBfcntl\fP() originel de Linux n'a pas été conçu pour gérer les positions (dans la structure \fIflock\fP) dans des fichiers de très grosse taille. En conséquence, Linux\ 2.4 a ajouté l'appel système \fBfcntl64\fP(). Ce nouvel appel système utilise une structure différente de verrouillage de fichier, \fIflock64\fP, ainsi que les commandes correspondantes \fBF_GETLK64\fP, \fBF_SETLK64\fP et \fBF_SETLKW64\fP. Cependant, ces détails peuvent être ignorés par les applications qui utilisent la glibc, car sa fonction \fBfcntl\fP() encapsule de manière transparente l'appel système le plus récent disponible. .SS "Verrouillages d’enregistrements et NFS" .\" .\" Neil Brown: With NFSv3 the failure mode is the reverse. If .\" the server loses contact with a client then any lock stays in place .\" indefinitely ("why can't I read my mail"... I remember it well). .\" .\" .\" Jeff Layton: .\" Note that this is not a firm timeout. The server runs a job .\" periodically to clean out expired stateful objects, and it's likely .\" that there is some time (maybe even up to another whole lease period) .\" between when the timeout expires and the job actually runs. If the .\" client gets a RENEW in there within that window, its lease will be .\" renewed and its state preserved. .\" Avant Linux\ 3.12, si un client NFSv4 perd le contact avec le serveur pendant un certain temps (défini à plus de 90\ secondes sans communication), il pourrait perdre puis obtenir un nouveau verrou sans même en être informé. (La période au bout de laquelle le contact est assumé perdu est connue sous le nom de période de bail («\ leasetime\ ») NFSv4. Sur un serveur NFS Linux, elle peut être déterminée en regardant \fI/proc/fs/nfsd/nfsv4leasetime\fP, qui exprime la période en seconde. La valeur par défaut pour ce fichier est 90.) Ce scénario a pour risque potentiel la corruption de données, puisqu’un autre processus pourrait obtenir un verrou pendant la période intermédiaire et réaliser des entrées et sorties de fichier. .PP .\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d .\" commit f6de7a39c181dfb8a2c534661a53c73afb3081cd Depuis Linux\ 3.12, si un client NFSv4 perd le contact avec le serveur, toutes les entrées et sorties du fichier par un processus qui «\ pense\ » détenir un verrou échoueront avant que le processus ne ferme et rouvre le fichier. Un paramètre du noyau, \fInfs.recover_lost_locks\fP, peut être défini à \fB1\fP pour obtenir le comportement précédant (avant Linux\ 3.12), où le client essayera de récupérer les verrous perdus quand le contact avec le serveur est rétabli. À cause du risque associé de corruption de données, la valeur par défaut de ce paramètre est \fB0\fP (désactivé). .SH BOGUES .SS F_SETFL .\" FIXME . According to POSIX.1-2001, O_SYNC should also be modifiable .\" via fcntl(2), but currently Linux does not permit this .\" See http://bugzilla.kernel.org/show_bug.cgi?id=5994 Il n'est pas possible d'utiliser \fBF_SETFL\fP pour modifier l'état des attributs \fBO_DSYNC\fP et \fBO_SYNC\fP. Une tentative de modification de ces attributs sera simplement ignorée. .SS F_GETOWN .\" glibc source: sysdeps/unix/sysv/linux/i386/sysdep.h .\" mtk, Dec 04: some limited testing on alpha and ia64 seems to .\" indicate that ANY negative PGID value will cause F_GETOWN .\" to misinterpret the return as an error. Some other architectures .\" seem to have the same range check as i386. En raison d'une limitation des conventions d'appels système sur certaines architectures (en particulier i386), si \fBF_GETOWN\fP renvoie un identifiant de groupe de processus compris entre \-1 et \-4095, la valeur de retour est interprétée par glibc comme une erreur\ ; la valeur de retour de \fBfcntl\fP() sera \-1 et \fIerrno\fP contiendra l'identifiant du groupe de processus (positif). L’opération spécifique à Linux \fBF_SETOWN_EX\fP évite ce problème. Depuis la glibc 2.11, glibc rend le problème avec \fBF_GETOWN\fP invisible en implémentant \fBF_GETOWN\fP par\-dessus \fBF_GETOWN_EX\fP. .SS F_SETOWN .\" Sous Linux 2.4 et précédents, lorsqu'un processus non privilégié utilise \fBF_SETOWN\fP pour indiquer le propriétaire d'un socket, avec un identifiant de (groupe de) processus autre que celui de l'appelant, un bogue peut survenir. Dans ce cas, \fBfcntl\fP() peut renvoyer \fB\-1\fP, avec \fIerrno\fP positionné à \fBEPERM\fP, même si l'appelant a le droit d'envoyer un signal à ce (groupe de) processus. En dépit de cette erreur, le propriétaire du descripteur de fichier est positionné, et les signaux seront envoyés au propriétaire. .SS "Détection d’interblocage" .\" L’algorithme de détection d’interblocage utilisé par le noyau lors du traitement de demandes \fBF_SETLKW\fP peut produire à la fois des faux négatifs (échec de détection d’interblocages, laissant un ensemble de processus interbloqués se bloquer indéfiniment) et des faux positifs (erreurs \fBEDEADLK\fP alors qu’aucun interblocage n’existe). Par exemple, le noyau limite la profondeur de verrouillage lors de sa recherche de dépendances à dix étapes, ce qui signifie que les chaînes d’interblocages circulaires dépassant cette taille ne seront pas détectées. De plus, le noyau pourrait faussement indiquer un interblocage lorsqu’au moins deux processus créés en utilisant l’attribut \fBCLONE_FILES\fP de \fBclone\fP(2) placent des verrous qui semblent (au noyau) en conflit. .SS "Verrouillage impératif" .\" http://marc.info/?l=linux-kernel&m=119013491707153&w=2 .\" .\" Reconfirmed by Jeff Layton .\" From: Jeff Layton redhat.com> .\" Subject: Re: Status of fcntl() mandatory locking .\" Newsgroups: gmane.linux.file-systems .\" Date: 2014-04-28 10:07:57 GMT .\" http://thread.gmane.org/gmane.linux.file-systems/84481/focus=84518 L'implémentation Linux du verrouillage impératif est sujette à des conditions de concurrence qui la rende non fiable\ : un appel à \fBwrite\fP(2) qui chevauche un verrou peut modifier les données après que le verrouillage impératif a été acquis\ ; un appel à \fBread\fP(2) qui chevauche un verrou peut détecter des modifications sur des données qui ont été faites seulement après qu'un verrou en écriture a été acquis. Des conditions de concurrence similaires existent entre les verrous impératifs et \fBmmap\fP(2). Il est donc déconseillé de faire confiance au verrouillage impératif. .SH "VOIR AUSSI" \fBdup2\fP(2), \fBflock\fP(2), \fBopen\fP(2), \fBsocket\fP(2), \fBlockf\fP(3), \fBcapabilities\fP(7), \fBfeature_test_macros\fP(7), \fBlslocks\fP(8) .PP \fIlocks.txt\fP, \fImandatory\-locking.txt\fP et \fIdnotify.txt\fP dans le répertoire \fIDocumentation/filesystems/\fP des sources du noyau Linux. (Sur d'anciens noyaux, ces fichiers se trouvent dans le répertoire \fIDocumentation/\fP et \fImandatory\-locking.txt\fP est appelé \fImandatory.txt\fP.) .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot et Jean-Philippe MENGUAL . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .