Ubuntu Manpage: fcntl - Manipuler un descripteur de fichier

NOM

       fcntl - Manipuler un descripteur de fichier

SYNOPSIS

       #include <unistd.h>
       #include <fcntl.h>

       int fcntl(int fd, int cmd, ... /* arg */ );

DESCRIPTION

fcntl() permet de se livrer à diverses opérations sur le descripteur de fichier fd.
L'opération en question est déterminée par la valeur de l'argument cmd.

fcntl() accepte un troisième paramètre optionnel. La nécessité de fournir, ou pas, ce
paramètre dépend de cmd. Le paramètre doit être du type indiqué entre parenthèses après
chaque nom de commande cmd (dans la plupart des cas, le type requis est un int, et le
paramètre est identifié en utilisant le nom arg), ou void est indiqué si le paramètre
n'est pas nécessaire.

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 fcntl() avec la valeur de cmd voulue et ensuite de
tester si l’appel a échoué avec EINVAL, indiquant que le noyau ne reconnaît pas cette
valeur.

Dupliquer un descripteur de fichier
F_DUPFD (int)
Dupliquer le descripteur de fichier fd en utilisant le plus petit numéro de
descripteur de fichier libre supérieur ou égal à arg. Cela est différent de
dup2(2), qui utilise exactement le descripteur de fichier transmis.

En cas de réussite, le nouveau descripteur de fichier est renvoyé.

Consultez dup(2) pour plus d'informations.

F_DUPFD_CLOEXEC (int ; depuis Linux 2.6.24)
Comme pour F_DUPFD, 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 F_SETFD de fcntl() supplémentaire pour positionner
l'attribut FD_CLOEXEC. Pour une explication sur ce en quoi cet attribut est utile,
consultez la description de O_CLOEXEC dans open(2).

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 FD_CLOEXEC, l'attribut « close‐
on‐exec ». Si le bit FD_CLOEXEC est positionné, le descripteur de fichier sera
automatiquement fermé lors d'un execve(2) réussi (si execve(2) échoue, le descripteur de
fichier reste ouvert). Si le bit FD_CLOEXEC n'est pas positionné, le descripteur de
fichier restera ouvert à la fin d’un execve(2).

F_GETFD (void)
Renvoyer (en tant que résultat de la fonction) les attributs du descripteur de
fichier ; arg est ignoré.

F_SETFD (int)
Positionner les attributs du descripteur de fichier avec la valeur précisée par
arg.

Dans un programme multithreadé, l'utilisation simultanée dans un thread de fcntl() avec
F_SETFD afin de définir l'attribut « close-on-exec » (FD_CLOEXEC), et de fork(2) suivi de
execve(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 O_CLOEXEC dans open(2) qui
décrivent une solution à ce problème.

Attribut d'état du fichier
Un descripteur de fichier dispose de certains attributs d’état, initialisés par open(2) et
éventuellement modifiés par fcntl(). Les descripteurs de fichier dupliqués (obtenus avec
dup(2), fcntl(F_DUPFD), fork(2), etc.) concernent la même description de fichier ouvert,
et par conséquent partagent les mêmes attributs d’état de fichier.

Les attributs et leurs sémantiques sont décrits dans la page open(2).

F_GETFL (void)
Renvoyer (en tant que résultat de la fonction) les droits d'accès du fichier et les
drapeaux d'état du fichier ; arg est ignoré.

F_SETFL (int)
Positionner les drapeaux d'état du fichier à la valeur indiquée par arg. Les
drapeaux des droits d'accès au fichier (O_RDONLY, O_WRONLY, O_RDWR) et les
attributs de création du fichier (O_CREAT, O_EXCL, O_NOCTTY, O_TRUNC) de arg sont
ignorés. Sous Linux, cette commande ne peut changer que les attributs O_APPEND,
O_ASYNC, O_DIRECT, O_NOATIME et O_NONBLOCK. Modifier les attributs O_DSYNC et
O_SYNC est impossible, consultez BOGUES ci-dessous.

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.

F_SETLK, F_SETLKW et F_GETLK servent à gérer les verrouillages d'enregistrements
(d’intervalle d’octets, de segments de fichiers ou de zones de fichiers). Le troisième
argument, lock, est un pointeur sur une structure qui a au moins les champs suivants (dans
un ordre non indiqué).

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) */
...
};

Les champs l_whence, l_start et l_len 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.

l_start est la position de début du verrou, et est interprété de façon relative : au début
du fichier (si l_whence vaut SEEK_SET) ; à la position actuelle dans le fichier (si
l_whence vaut SEEK_CUR) ; à la fin du fichier (si l_whence vaut SEEK_END). Dans les deux
derniers cas, l_start peut être un nombre négatif, à partir du moment où la position
fournie ne pointe pas avant le début du fichier.

l_len indique le nombre d'octets à verrouiller. Si l_len est positif, alors l'intervalle à
verrouiller couvre les octets à partir de l_start jusqu'à l_start+l_len-1 (inclus).
Indiquer 0 dans l_len a une signification particulière : cela verrouille tous les octets à
partir de la position indiquée par l_whence et l_start jusqu'à la fin du fichier, quelle
que soit la taille que prendra le fichier.

POSIX.1-2001 permet (mais n'impose pas) à une implémentation de prendre en charge des
valeurs de l_len négatives ; si l_len est négatif, l'intervalle décrivant le verrou lock
couvre les octets l_start+l_len jusqu'à l_start-1 inclus. Cela est géré par Linux depuis
les versions 2.4.21 et 2.5.49.

Le champ l_type peut servir à placer un verrou en lecture (F_RDLCK) ou en écriture
(F_WRLCK) 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.

F_SETLK (struct flock *)
Acquérir (si l_type vaut F_RDLCK ou F_WRLCK) ou libérer (si l_type vaut F_UNLCK) le
verrou sur les octets indiqués par les champs l_whence, l_start, et l_len de lock.
Si un conflit avec un verrou tenu par un autre processus existe, cet appel renvoie
-1 et positionne errno aux valeurs EACCES ou EAGAIN (l’erreur renvoyée dans ce cas
dépend des implémentations, donc POSIX impose aux applications portables de
vérifier les deux erreurs).

F_SETLKW (struct flock *)
Comme F_SETLK, 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 -1. errno sera remplie avec la valeur EINTR ;
consultez signal(7).

F_GETLK (struct flock *)
En entrée dans cette routine, lock décrit un verrou que nous aimerions placer sur
le fichier. Si le verrouillage est possible, fcntl() ne le fait pas, mais renvoie
F_UNLCK dans le champ l_type de lock et laisse les autres champs de la structure
inchangés.

Si un ou plusieurs verrouillages incompatibles empêchaient l'action, alors fcntl()
renvoie des informations sur l'un de ces verrous dans les champs l_type, l_whence,
l_start, et l_len de lock. Si le verrouillage en conflit est un verrouillage
d’enregistrements UNIX traditionnels (« associé au processus »), alors le champ
l_pid 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 l_pid est
défini à -1. Remarquez que les renseignements renvoyés pourraient déjà être périmés
au moment ou l’appelant les inspecte.

Pour pouvoir placer un verrou en lecture, fd doit être ouvert au moins en lecture. Pour
placer un verrou en écriture, fd doit être ouvert en écriture. Pour placer les deux types
de verrous, il faut une ouverture en lecture/écriture.

Lors du placement de verrous avec F_SETLKW, le noyau détecte les interblocages
(deadlocks), 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
F_SETLKW, 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 EDEADLK ; 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 BOGUES.

Outre la suppression par un F_UNLCK explicite, les verrous sont automatiquement libérés
lorsque le processus se termine.

Les verrouillages d'enregistrements ne sont pas hérités par les enfants lors d'un fork(2),
mais sont conservés à la fin d'un execve(2).

À cause des tampons gérés par la bibliothèque stdio(3), l'utilisation des verrous
d'enregistrements avec les routines de celle‐ci est déconseillée. Utilisez plutôt read(2)
et write(2).

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.

– Si le processus ferme l'un 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 /etc/passwd
ou /etc/mtab si, pour une raison quelconque, une fonction de bibliothèque décide
d’ouvrir, lire, puis refermer le même fichier.

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

Les verrouillages de description de fichier ouvert apportent une solution à ces deux
problèmes.

Verrouillages de description de fichier ouvert (non POSIX)
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 open(2).

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 flock(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 fork(2) (et clone(2)
avec CLONE_FILES) 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.

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.

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 fork(2), dup(2), fcntl(2) F_DUPFD, 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).

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’open(2) sur le fichier et utilisent les
verrouillages à l’aide du descripteur de fichier qui en résulte.

Comme avec les verrouillages coopératifs traditionnels, le troisième argument de fcntl(),
lock, est un pointeur vers une structure flock. Contrairement aux verrouillages
d’enregistrements traditionnels, le champ l_pid de cette structure doit être mis à zéro
lors de l’utilisation des commandes décrites ci-dessous.

Les commandes permettant d’interagir avec les verrouillages de description de fichier
ouvert sont similaires à celles utilisées avec les verrouillages traditionnels.

F_OFD_SETLK (struct flock *)
Acquérir (si l_type vaut F_RDLCK ou F_WRLCK) ou libérer (si l_type vaut F_UNLCK) un
verrou de description de fichier ouvert sur les octets indiqués par les champs
l_whence, l_start et l_len de lock. Si un conflit avec un verrou détenu par un
autre processus existe, cet appel renvoie -1 et définit errno à EAGAIN.

F_OFD_SETLKW (struct flock *)
Comme F_OFD_SETLK, 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 -1 et errno sera définie à EINTR ; consultez signal(7).

F_OFD_GETLK (struct flock *)
En entrée dans cette routine, lock décrit un verrou de description de fichier
ouvert que nous aimerions placer sur le fichier. Si le verrouillage est possible,
fcntl() ne le fait pas, mais renvoie F_UNLCK dans le champ l_type de lock 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 lock, comme décrit précédemment pour F_GETLK.

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

Verrouillage impératif
Attention : 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 (CONFIG_MANDATORY_FILE_LOCKING). C'est
la première étape vers la suppression complète de cette fonctionnalité.

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.

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 read(2) ou write(2)) sur une zone d'un fichier qui a un verrou impératif, le
résultat dépend de l'attribut O_NONBLOCK 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 O_NONBLOCK est activé, l'appel système
échoue avec l'erreur EAGAIN.

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 « -o mand »
de mount(8)), ou l'attribut MS_MANDLOCK de mount(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 chmod(1) et chmod(2)).

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.

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.

Quand un système de fichiers détermine qu'un verrou est perdu, les futures requêtes
read(2) ou write(2) peuvent échouer avec l'erreur EIO. 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).

Certaines versions d'UNIX envoient un signal (SIGLOST) dans ce cas. Linux ne définit pas
ce signal et il ne fournit pas de notification asynchrone de perte de verrous.

Gestion des signaux
F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_GETSIG et F_SETSIG servent à gérer les
signaux de disponibilité d'entrée-sortie :

F_GETOWN (void)
Renvoyer (comme résultat de la fonction) le PID ou l'ID de processus qui reçoit les
signaux SIGIO et SIGURG pour les événements concernant le descripteur de fichier
fd. 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‐dessous). arg est ignoré.

F_SETOWN (int)
Définir le PID ou l'identifiant de processus qui recevront les signaux SIGIO et
SIGURG pour les événements concernant le descripteur fd. L'ID de processus ou de
groupe de processus cible est indiqué dans arg. 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 (arg est donc getpid(2)).

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 F_SETFL de fcntl() pour positionner le drapeau d'état du
fichier O_ASYNC sur le descripteur de fichier. Par conséquent, un signal SIGIO est
envoyé dès que l'entrée ou la sortie sont possibles sur ce descripteur. La commande
F_SETSIG de fcntl() peut être utilisée pour recevoir un autre signal que SIGIO.

L'envoi d'un signal au processus (ou groupe de processus) propriétaire indiqué par
F_SETOWN est conditionné par les mêmes vérifications de permissions que l'envoi
d'un signal par kill(2), où le processus envoyant le signal est celui qui utilise
F_SETOWN (mais consultez la section BOGUES ci‐dessous). Si cette vérification
échoue, le signal est ignoré silencieusement. Note : l'opération F_SETOWN
enregistre les droits de l'appelant utilisés lors de l'appel fcntl() pour les
vérifications de permissions.

Si le descripteur fd est un socket, F_SETOWN permet également la réception de
signaux SIGURG lorsque des données hors‐bande arrivent sur le socket. (SIGURG est
émis dans toutes les situations où l'appel select(2) aurait indiqué que le socket
est dans une « situation exceptionnelle ».)

Le paragraphe ci-dessous était pertinent pour les noyaux 2.6.x, jusqu'au 2.6.11
inclus :

Si une valeur non nulle est passée à F_SETSIG dans un processus multithreadé
utilisant une bibliothèque de threads gérant les groupes de threads (par
exemple NPTL), une valeur positive passée à F_SETOWN 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 à F_SETOWN la
valeur renvoyée par gettid(2) plutôt que celle renvoyée par getpid(2) pour
obtenir les résultats souhaités si F_SETSIG 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 gettid(2)
ou getpid(2).) Veuillez toutefois noter que les remarques de ce paragraphe
ne s'appliquent pas au signal SIGURG généré lorsque des données hors‐bande
sont disponibles sur un socket : ce signal est toujours envoyé soit à un
processus, soit à un groupe de processus, selon la valeur donnée à F_SETOWN.

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 F_SETOWN_EX pour envoyer les signaux
SIGIO et SIGURG à un thread en particulier.

F_GETOWN_EX (struct f_owner_ex *) (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 F_SETOWN_EX. L'information est renvoyée
dans la structure pointée par arg, qui a la forme suivante :

struct f_owner_ex {
int type;
pid_t pid;
};

Le champ type aura l'une des valeurs F_OWNER_TID, F_OWNER_PID ou F_OWNER_PGRP. Le
champ pid est un entier positif représentant un identifiant de thread, de processus
ou de groupe de processus. Consultez F_SETOWN_EX pour plus de détails.

F_SETOWN_EX (struct f_owner_ex *) (depuis Linux 2.6.32)
Cette opération effectue une tâche similaire à F_SETOWN. 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 arg, qui est un pointeur vers une structure f_owner_ex. Le champ type
possède l'une des valeurs suivantes, qui définit comment pid est interprété :

F_OWNER_TID
Envoyer le signal au thread dont l'identifiant (la valeur renvoyée par un
appel à clone(2) ou gettid(2)) est indiqué par pid.

F_OWNER_PID
Envoyer le signal au processus dont l'identifiant est indiqué par pid.

F_OWNER_PGRP
Envoyer le signal au groupe de processus dont l'identifiant est indiqué par
pid. Notez que, à la différence de F_SETOWN, un identifiant de groupe de
processus est indiqué ici avec une valeur positive.

F_GETSIG (void)
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 SIGIO.
Toute autre valeur (y compris SIGIO) précise le signal émis, et des informations
supplémentaires seront disponibles pour le gestionnaire s'il est installé avec
SA_SIGINFO. arg est ignoré.

F_SETSIG (int)
Définir le signal à émettre lorsque l'entrée ou la sortie deviennent possibles à la
valeur fournie par arg. Une valeur nulle signifie l'émission de SIGIO. Toute autre
valeur (y compris SIGIO) précise le signal à émettre, et des informations
supplémentaires seront disponibles pour le gestionnaire s'il est installé avec
SA_SIGINFO.

En utilisant F_SETSIG avec une valeur non nulle, et en configurant SA_SIGINFO pour
le gestionnaire (consultez sigaction(2)), des informations supplémentaires sur les
événements d'entrées-sorties sont fournies au gestionnaire à travers une structure
siginfo_t. Si le champ si_code indique que la source est SI_SIGIO, le champ si_fd
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 (select(2), poll(2), read(2) avec O_NONBLOCK configuré, etc.)
pour déterminer quels descripteurs de fichier sont disponibles pour les
entrées-sorties.

Remarquez que le descripteur de fichier fourni dans si_fd est celui indiqué lors de
l'opération F_SETSIG. Cela peut provoquer un effet de bord inhabituel. Si le
descripteur de fichier est dupliqué (dup(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 si_fd contiendra le numéro du descripteur de fichier à présent fermé.

En sélectionnant un signal temps réel (valeur >= SIGRTMIN), 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‐dessus, si SA_SIGINFO est configuré pour le gestionnaire.

Notez que Linux impose une limite sur le nombre de signaux temps réel qui peuvent
être mis en attente pour un processus (consultez getrlimit(2) et signal(7)), et si
cette limite est atteinte, le noyau change de comportement et envoie SIGIO, et ce
signal est délivré au processus entier plutôt qu'au thread spécifique.

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 select(2) ou poll(2).

L'utilisation de O_ASYNC est spécifique à BSD et Linux. La seule utilisation de F_GETOWN
et F_SETOWN spécifiée dans POSIX.1 est en conjonction avec l’utilisation du signal SIGURG
sur les sockets (POSIX ne spécifie pas le signal SIGIO). F_GETOWN_EX, F_SETOWN_EX,
F_GETSIG et F_SETSIG sont spécifiques à Linux. POSIX dispose d'entrées-sorties asynchrones
et de la structure aio_sigevent pour effectuer la même chose. Cela est également
disponible sous Linux dans la bibliothèque GNU C (Glibc).

Baux
F_SETLEASE et F_GETLEASE (depuis Linux 2.4) servent respectivement à établir un nouveau
bail et à consulter le bail actuel sur le descripteur de fichier indiqué par fd. (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 open(2)
ou truncate(2) sur le fichier vers lequel pointe ce descripteur de fichier.

F_SETLEASE (int)
Définir ou supprimer un bail de fichier en fonction de la valeur fournie dans
l'entier arg :

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

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

F_UNLCK
Supprimer le bail sur un fichier.

Les baux sont associés à une description de fichier ouvert (consultez open(2)). Cela
signifie que les descripteurs de fichier dupliqués (créés par, par exemple, fork(2) ou
dup(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
F_UNLCK explicite sur n'importe lequel de ces descripteurs dupliqués, soit lorsque tous
ces descripteurs ont été fermés.

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é CAP_LEASE peut prendre un bail sur
n'importe quel fichier.

F_GETLEASE (void)
Indiquer le type de bail possédé sur le descripteur de fichier fd en renvoyant
F_RDLCK, F_WRLCK, ou F_UNLCK, signifiant respectivement que le processus appelant a
un bail en lecture, écriture, ou pas de bail sur le fichier. arg est ignoré.

Lorsqu'un processus (le « casseur de bail ») appelle open(2) ou truncate(2) en conflit
avec un bail établi par F_SETLEASE, l'appel système est bloqué par le noyau et le noyau
avertit le processus tenant le bail par l'envoi d'un signal (SIGIO 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 F_SETLEASE avec arg valant F_UNLCK. 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 F_SETLEASE avec arg valant F_RDLCK.

Si le détenteur du bail n'arrive pas à le déclasser ou le supprimer avant le nombre de
secondes indiqué dans /proc/sys/fs/lease-break-time alors le noyau supprimera ou
déclassera de force le bail du processus qui le détient.

Dès qu'un cassage de bail a été commencé, F_GETLEASE renvoie le type de bail cible
(F_RDLCK ou F_UNLCK, 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.

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.

Si l'appel à open(2) ou truncate(2) du casseur de bail est interrompu par un gestionnaire
de signal, l'appel système échoue avec l'erreur EINTR, mais les autres étapes décrites ci‐
dessous se déroulent normalement. Si le casseur de bail est tué par un signal pendant que
son appel système open(2) ou truncate(2) bloque, tout se déroule comme décrit ci‐dessus.
De même, si le casseur de bail utilise l'option O_NONBLOCK de open(2), l'appel retourne
immédiatement avec l'erreur EWOULDBLOCK, mais les autres étapes se déroulent comme décrit
ci‐dessus.

Le signal de notification par défaut pour le tenant du bail est SIGIO, mais on peut le
modifier avec la commande F_SETSIG de la fonction fcntl(). Si une commande F_SETSIG est
réalisée (même pour SIGIO), et si le gestionnaire de signal est installé avec SA_SIGINFO,
alors il recevra une structure siginfo_t en second argument, et le champ si_fd 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.)

Notification de modification de fichier et de répertoire (dnotify)
F_NOTIFY (int)
(Depuis Linux 2.4) Fournir un avertissement lorsque le répertoire correspondant à
fd ou l'un des fichiers qu'il contient est modifié. Les événements à notifier sont
précisés dans arg, sous forme de masque regroupant par un OU binaire zéro, une ou
plusieurs des constantes suivantes :

DN_ACCESS
Accès à un fichier (read(2), pread(2), readv(2) et similaires)
DN_MODIFY
Modification d'un fichier (write(2), pwrite(2), writev(2), truncate(2),
ftruncate(2) et similaires).
DN_CREATE
Création d'un fichier (open(2), creat(2), mknod(2), mkdir(2), link(2),
symlink(2), rename(2) dans ce répertoire).
DN_DELETE
Suppression d'un fichier (unlink(2), rename(2) dans un autre répertoire,
rmdir(2)).
DN_RENAME
Un fichier a été renommé dans le même répertoire (rename(2)).
DN_ATTRIB
Les attributs d'un fichier ont été modifiés (chown(2), chmod(2), utime(2),
utimensat(2) et similaires).

(Afin d'obtenir ces définitions, la macro _GNU_SOURCE doit être définie avant
d'inclure tout fichier d'en‐tête).

Les notifications de répertoire sont habituellement uniques, et l'application doit
réenregistrer une demande pour les notifications ultérieures. Inversement, si
DN_MULTISHOT est incluse dans arg, les notifications resteront en effet jusqu'à une
demande explicite de suppression.

Une série de F_NOTIFY sont cumulés, les événements décrits dans arg étant ajoutés à
l'ensemble des événements déjà surveillés. Pour supprimer les notifications de tous
les événements, il faut invoquer F_NOTIFY avec arg valant 0.

La notification se produit par l'occurrence d'un signal. Le signal par défaut est
SIGIO, mais on peut le changer avec la commande F_SETSIG de fcntl() (remarquez que
SIGIO 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 siginfo_t en second argument (si le gestionnaire a été
installé avec SA_SIGINFO) dont le champ si_fd contient le descripteur du fichier
qui a déclenché la notification (utile pour superviser plusieurs répertoires).

En outre, avec DN_MULTISHOT, un signal temps réel devrait être utilisé pour la
notification pour pouvoir empiler les notifications successives.

Remarque : les nouvelles applications devraient utiliser l'interface inotify
(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
inotify(7).

Changer la capacité d'un tube
F_SETPIPE_SZ (int ; depuis Linux 2.6.35)
Changer la capacité du tube référencé par fd pour contenir au moins arg 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
/proc/sys/fs/pipe-max-size (consultez proc(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 /proc/sys/fs/pipe-max-size renvoie l'erreur EPERM ;
un processus privilégié (CAP_SYS_RESOURCE) peut passer outre cette limite.

Lors de l'affectation d'un tampon à un tube, le noyau peut utiliser une capacité
supérieure à arg, 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.

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

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.

F_GETPIPE_SZ (void ; depuis Linux 2.6.35)
Renvoyer (comme résultat de la fonction) la capacité du tube référencé par fd.

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 EPERM à 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 memfd_create(2).

Actuellement, les verrous de fichier ne peuvent être appliqués que sur un descripteur de
fichier renvoyé par memfd_create(2) (si MFD_ALLOW_SEALING est utilisé). Sur d'autres
systèmes de fichiers, toutes les opérations de fcntl() agissant sur les verrous renverront
EINVAL.

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.

F_ADD_SEALS (int ; depuis Linux 3.17)
Ajouter les verrous donnés dans le paramètre arg du masque de bit à l'ensemble de
verrous de l'inœud auquel se rapporte le descripteur de fichier fd. 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
F_SEAL_SEAL (voir ci-dessous), cet appel sera rejeté avec EPERM. L'ajout d'un
verrou déjà défini n'est pas opérationnel, si F_SEAL_SEAL n'est pas déjà
positionné. Pour positionner un verrou, le descripteur de fichier fd doit être
accessible en écriture.

F_GET_SEALS (void ; 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 fd. Si aucun verrou n'est positionné, 0 est renvoyé. Si le
fichier ne gère pas les verrous, -1 est renvoyé et errno est positionné sur EINVAL.

Les verrous suivants sont disponibles :

F_SEAL_SEAL
Si ce verrou est positionné, tout appel suivant à fcntl() avec F_ADD_SEALS échouera
avec l'erreur EPERM. Ce verrou empêche donc toute modification du jeu de verrous
lui-même. Si le jeu de verrous initial du fichier comprend F_SEAL_SEAL, cela le
rend en fait constant et verrouillé.

F_SEAL_SHRINK
Si ce verrou est positionné, le fichier en question ne peut pas voir sa taille
réduite. Cela concerne open(2) avec le drapeau O_TRUNC ainsi que truncate(2) et
ftruncate(2). Ces appels échouent avec EPERM si vous essayez de réduire le fichier
en question. Augmenter la taille reste possible.

F_SEAL_GROW
Si ce verrou est positionné, le fichier en question ne peut pas voir sa taille
augmentée. Cela concerne write(2) après la fin du fichier, truncate(2),
ftruncate(2) et fallocate(2). Ces appels échoueront avec EPERM 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.

F_SEAL_WRITE
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 write(2) et fallocate(2) (combiné au drapeau
FALLOC_FL_PUNCH_HOLE). Ces appels échoueront avec EPERM si ce verrou est
positionné. De plus, les tentatives de créer de nouveaux tableaux de mémoire
(memory-mappings) accessibles en écriture avec mmap(2) échoueront également avec
EPERM.

L'utilisation de l'opération F_ADD_SEALS pour définir le verrou F_SEAL_WRITE échoue
avec EBUSY 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 (io_submit(2)) en attente sur le fichier, toutes les
écritures postérieures seront ignorées.

F_SEAL_FUTURE_WRITE (depuis Linux 5.1)
L'effet de ce verrou est identique à F_SEAL_WRITE, 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 mmap(2) échouera avec EPERM. De même,
une tentative d'écriture dans le fichier avec write(2) échouera avec EPERM.

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.

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 open(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.

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.

Les opérations suivantes peuvent être appliquées au descripteur de fichier, fd :

F_GET_RW_HINT (uint64_t * ; depuis Linux 4.13)
Renvoie la valeur de référence (« hint ») de lecture/écriture associée à l'inœud
sous-jacent auquel renvoie fd.

F_SET_RW_HINT (uint64_t * ; depuis Linux 4.13)
Définit la valeur de référence de lecture/écriture associée à l'inœud sous-jacent
auquel renvoie fd. 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é.

F_GET_FILE_RW_HINT (uint64_t * ; depuis Linux 4.13)
Renvoie la valeur de référence « hint » de lecture/écriture associée à la
description de fichier ouvert à laquelle renvoie fd.

F_SET_FILE_RW_HINT (uint64_t * ; 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 fd.

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.

Les valeurs de référence de lecture/écriture suivantes sont applicables depuis Linux
4.13 :

RWH_WRITE_LIFE_NOT_SET
Aucune valeur de référence en particulier n'a été définie. Il s'agit de la valeur
par défaut.

RWH_WRITE_LIFE_NONE
Aucune durée de vie spécifique à l'écriture n'a été associée à ce fichier ou à cet
inœud.

RWH_WRITE_LIFE_SHORT
Les données écrites dans cet inœud ou via cette description de fichier ouvert
doivent avoir une durée de vie courte.

RWH_WRITE_LIFE_MEDIUM
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
RWH_WRITE_LIFE_SHORT.

RWH_WRITE_LIFE_LONG
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
RWH_WRITE_LIFE_MEDIUM.

RWH_WRITE_LIFE_EXTREME
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
RWH_WRITE_LIFE_LONG.

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

VALEUR RENVOYÉE

       Pour qu'un appel réussisse, le code de retour dépend de l'opération :

       F_DUPFD
              Le nouveau descripteur de fichier.

       F_GETFD
              Valeur des attributs du descripteur de fichier.

       F_GETFL
              Valeur des attributs d'état du fichier.

       F_GETLEASE
              Le type de bail tenu sur le descripteur de fichier.

       F_GETOWN
              Valeur du propriétaire du descripteur de fichier.

       F_GETSIG
              La  valeur  du signal envoyé lorsque la lecture ou l'écriture deviennent possibles,
              ou zéro pour le comportement SIGIO traditionnel.

       F_GETPIPE_SZ, F_SETPIPE_SZ
              La capacité du tube.

       F_GET_SEALS
              Un masque de bit identifiant les verrous positionnés sur le  inœud  auquel  renvoie
              fd.

       Toutes les autres commandes :
              Zéro.

       En cas d'erreur, la valeur de retour est -1, et errno est défini de façon appropriée.

ERREURS

EACCES ou EAGAIN
L'opération est interdite en raison de verrous tenus par d'autres processus.

EAGAIN L'opération est impossible à cause d'une projection en mémoire effectuée par un
autre processus.

EBADF fd n'est pas un descripteur de fichier ouvert

EBADF fd vaut F_SETLK ou F_SETLKW et les droits d'ouverture sur le descripteur de fichier
ne correspondent pas au type de verrou demandé.

EBUSY cmd vaut F_SETPIPE_SZ et la capacité du nouveau tube indiqué dans arg est
inférieure à la taille de l'espace du tampon actuellement utilisé pour stocker les
données dans le tube.

EBUSY cmd vaut F_ADD_SEALS, arg inclut F_SEAL_WRITE et il existe un tableau partagé
accessible en écriture sur le fichier auquel se rapporte fd.

EDEADLK
Le verrouillage F_SETLKW conduirait à un interblocage.

EFAULT lock se trouve en dehors de l'espace d'adressage.

EINTR cmd vaut F_SETLKW ou F_OFD_SETLKW et l'opération a été interrompue par un signal ;
voir signal(7).

EINTR cmd vaut F_GETLK, F_SETLK, F_OFD_GETLK ou F_OFD_SETLK 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.

EINVAL La valeur indiquée dans cmd n'est pas reconnue par ce noyau.

EINVAL cmd vaut F_ADD_SEALS et arg inclut un bit de verrou non reconnu.

EINVAL cmd vaut F_ADD_SEALS ou F_GET_SEALS et le système de fichiers contenant l'inœud
auquel se rapporte fd ne prend pas en charge les verrous.

EINVAL cmd vaut F_DUPFD et arg est négatif ou supérieur à la valeur maximale permise (voir
le point sur RLIMIT_NOFILE dans getrlimit(2)).

EINVAL cmd vaut F_SETSIG et arg n'est pas un numéro de signal autorisé.

EINVAL cmd est F_OFD_SETLK, F_OFD_SETLKW ou F_OFD_GETLK, et l_pid n’a pas été défini comme
nul.

EMFILE cmd vaut F_DUPFD et la limite par processus du nombre de descripteurs de fichier
ouverts a été atteinte.

ENOLCK Trop de verrous sont ouverts, ou la table des verrous est pleine, ou le
verrouillage distant (par exemple par NFS) a échoué.

ENOTDIR
F_NOTIFY a été indiqué dans cmd, mais fd ne fait pas référence à un répertoire.

EPERM cmd vaut F_SETPIPE_SZ et la limite rigide ou souple du tube de l'utilisateur a été
atteinte ; voir pipe(7).

EPERM Essai d'effacement de l'attribut O_APPEND sur un fichier, mais il est considéré
comme en-ajout-seulement.

EPERM cmd valait F_ADD_SEALS, mais fd n'était pas ouvert en écriture ou le jeu de verrous
actuel sur le fichier inclut déjà F_SEAL_SEAL.

CONFORMITÉ

       SVr4, 4.3BSD, POSIX.1-2001. Seules les  opérations  F_DUPFD,  F_GETFD,  F_SETFD,  F_GETFL,
       F_SETFL, F_GETLK, F_SETLK et F_SETLKW sont spécifiées dans POSIX.1-2001.

       F_GETOWN et F_SETOWN sont spécifiées dans POSIX.1-2001 (pour activer ces définitions, vous
       devez  définir  soit  _XOPEN_SOURCE  à  la  valeur  supérieure  ou  égale  à   500,   soit
       _POSIX_C_SOURCE à la valeur supérieure ou égale à 200809L).

       F_DUPFD_CLOEXEC est spécifiée dans POSIX.1-2008 (pour activer cette définition, vous devez
       définir _POSIX_C_SOURCE avec une valeur supérieure ou égale à  200809L,  ou  _XOPEN_SOURCE
       avec une valeur supérieure ou égale à 700).

       F_GETOWN_EX,   F_SETOWN_EX,  F_SETPIPE_SZ,  F_GETPIPE_SZ,  F_GETSIG,  F_SETSIG,  F_NOTIFY,
       F_GETLEASE et F_SETLEASE sont spécifiques à Linux. (Définissez la macro  _GNU_SOURCE  pour
       avoir ces définitions).

       F_OFD_SETLK,  F_OFD_SETLKW  et  F_OFD_GETLK  sont  spécifiques à Linux (et il faut définir
       _GNU_SOURCE pour obtenir leurs définitions), mais le travail est en cours pour  les  avoir
       dans la prochaine version de POSIX.1.

       F_ADD_SEALS et F_GET_SEALS sont spécifiques à Linux.

NOTES

Les erreurs renvoyées par dup2(2) ne sont pas les mêmes que celles renvoyées par F_DUPFD.

Verrouillages de fichier
L'appel système fcntl() originel de Linux n'a pas été conçu pour gérer les positions (dans
la structure flock) dans des fichiers de très grosse taille. En conséquence, Linux 2.4 a
ajouté l'appel système fcntl64(). Ce nouvel appel système utilise une structure différente
de verrouillage de fichier, flock64, ainsi que les commandes correspondantes F_GETLK64,
F_SETLK64 et F_SETLKW64. Cependant, ces détails peuvent être ignorés par les applications
qui utilisent la glibc, car sa fonction fcntl() encapsule de manière transparente l'appel
système le plus récent disponible.

Verrouillages d’enregistrements
Depuis le noyau 2.0, il n'y a pas d'interaction entre les types de verrous placés par
flock(2) et fcntl().

Plusieurs systèmes ont d'autres champs dans struct flock comme, par exemple, l_sysid (pour
identifier la machine où se trouve le verrou). Clairement, l_pid 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é.

L'appel système fcntl() originel de Linux n'a pas été conçu pour gérer les positions (dans
la structure flock) dans des fichiers de très grosse taille. En conséquence, Linux 2.4 a
ajouté l'appel système fcntl64(). Ce nouvel appel système utilise une structure différente
de verrouillage de fichier, flock64, ainsi que les commandes correspondantes F_GETLK64,
F_SETLK64 et F_SETLKW64. Cependant, ces détails peuvent être ignorés par les applications
qui utilisent la glibc, car sa fonction fcntl() encapsule de manière transparente l'appel
système le plus récent disponible.

Verrouillages d’enregistrements et NFS
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 /proc/fs/nfsd/nfsv4leasetime,
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.

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,
nfs.recover_lost_locks, peut être défini à 1 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 0 (désactivé).

BOGUES

   F_SETFL
       Il n'est pas possible d'utiliser F_SETFL pour modifier l'état  des  attributs  O_DSYNC  et
       O_SYNC. Une tentative de modification de ces attributs sera simplement ignorée.

   F_GETOWN
       En  raison  d'une  limitation des conventions d'appels système sur certaines architectures
       (en particulier i386), si F_GETOWN 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 fcntl() sera  -1  et  errno  contiendra  l'identifiant  du  groupe  de
       processus  (positif). L’opération spécifique à Linux F_SETOWN_EX évite ce problème. Depuis
       la glibc 2.11, glibc rend le problème avec F_GETOWN  invisible  en  implémentant  F_GETOWN
       par-dessus F_GETOWN_EX.

   F_SETOWN
       Sous  Linux  2.4  et  précédents, lorsqu'un processus non privilégié utilise F_SETOWN 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, fcntl() peut renvoyer -1,
       avec errno positionné à EPERM, 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.

   Détection d’interblocage
       L’algorithme de détection d’interblocage utilisé  par  le  noyau  lors  du  traitement  de
       demandes  F_SETLKW  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 EDEADLK 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 CLONE_FILES de clone(2)
       placent des verrous qui semblent (au noyau) en conflit.

   Verrouillage impératif
       L'implémentation  Linux  du  verrouillage  impératif  est  sujette  à  des  conditions  de
       concurrence  qui  la  rende  non fiable : un appel à write(2) qui chevauche un verrou peut
       modifier les données après que le verrouillage impératif a été acquis ; un appel à read(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 mmap(2). Il est donc déconseillé de
       faire confiance au verrouillage impératif.

VOIR AUSSI

       dup2(2), flock(2), open(2), socket(2), lockf(3), capabilities(7),  feature_test_macros(7),
       lslocks(8)

       locks.txt,     mandatory-locking.txt     et     dnotify.txt     dans     le     répertoire
       Documentation/filesystems/ des sources du noyau Linux. (Sur d'anciens noyaux, ces fichiers
       se  trouvent  dans  le  répertoire  Documentation/  et  mandatory-locking.txt  est  appelé
       mandatory.txt.)

COLOPHON

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

TRADUCTION

       La traduction française de cette  page  de  manuel  a  été  créée  par  Christophe  Blaess
       <https://www.blaess.fr/christophe/>,  Stéphan  Rafin  <stephan.rafin@laposte.net>, Thierry
       Vignaud <tvignaud@mandriva.com>, François Micaux, Alain  Portal  <aportal@univ-montp2.fr>,
       Jean-Philippe    Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)   <jean-
       luc.coulon@wanadoo.fr>,   Julien    Cristau    <jcristau@debian.org>,    Thomas    Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>,  Denis
       Barbier  <barbier@debian.org>,  David  Prévot <david@tilapin.org> et Jean-Philippe MENGUAL
       <jpmengual@debian.org>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  concernant  les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à debian-l10n-french@lists.debian.org ⟨⟩.