.\" -*- coding: UTF-8 -*- .\" Copyright 1992, Drew Eckhardt .\" Copyright 2016, Michael Kerrisk .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH close 2 "8 février 2026" "Pages du manuel de Linux 6.18" .SH NOM close \- Fermer un descripteur de fichier .SH BIBLIOTHÈQUE Bibliothèque C standard (\fIlibc\fP,\ \fI\-lc\fP) .SH SYNOPSIS .nf \fB#include \fP .P \fBint close(int \fP\fIfd\fP\fB);\fP .fi .SH DESCRIPTION \fBclose\fP() ferme le descripteur de fichier \fIfd\fP, de manière à ce qu'il ne référence plus aucun fichier, et puisse être réutilisé. Tous les verrouillages (consultez \fBfcntl\fP(2)) sur le fichier qui lui était associé, appartenant au processus, sont supprimés quel que soit le descripteur de fichier qui fut utilisé pour obtenir le verrouillage. Cela a quelques conséquences malheureuses il convient d'être extrêmement prudent lors de l'utilisation de verrouillages d’enregistrements coopératifs. Voir \fBfcntl\fP(2) pour une discussion sur les risques et conséquences et sur l'utilisation (probablement préférable) des verrouillages de description de fichier ouvert. .P Si \fIfd\fP est le dernier descripteur de fichier qui se réfère à une description de fichier ouvert sous\-jacente (consultez \fBopen\fP(2)), les ressources associées à la description de fichier ouvert sont libérées. Si le descripteur était la dernière référence sur un fichier supprimé avec \fBunlink\fP(2), le fichier est effectivement effacé. .SH "VALEUR RENVOYÉE" Si elle réussit, la fonction \fBclose\fP() renvoie zéro. En cas d'erreur, elle renvoie \fB\-1\fP et elle remplit \fIerrno\fP pour indiquer l'erreur. .SH ERREURS .TP \fBEBADF\fP Le descripteur de fichier \fIfd\fP est invalide. .TP \fBEINTR\fP .\" Though, it's in doubt whether this error can ever occur; see .\" https://lwn.net/Articles/576478/ "Returning EINTR from close()" L'appel système \fBclose\fP() a été interrompu par un signal ; consultez \fBsignal\fP(7). .TP \fBEIO\fP Une erreur d'entrée\-sortie s'est produite. .TP \fBENOSPC\fP .TQ \fBEDQUOT\fP Sur NFS, ces erreurs ne sont en principe pas signalées lors de la première écriture qui dépasse l'espace de stockage disponible, mais lors d'un \fBwrite\fP(2), \fBfsync\fP(2) ou \fBclose\fP() consécutif. .P See CAVEATS for a discussion of why \fBclose\fP() should not be retried after an error. .SH NORMES POSIX.1\-2008. .SH HISTORIQUE .\" SVr4 documents an additional ENOLINK error condition. 4.3BSD, SVr4, POSIX.1\-1988. .SH NOTES L'attribut de descripteur de fichier close\-on\-exec peut être utilisé pour s'assurer qu'un descripteur de fichier est fermé automatiquement en cas de succès de \fBexecve\fP(2) ; voir \fBfcntl\fP(2) pour des détails. .SH CAVEATS .\" Une fermeture sans erreur ne garantit pas que les données ont été vraiment écrites sur le disque, car le noyau repousse les écritures le plus tard possible. Il n'est pas fréquent qu'un système de fichiers vide les tampons dès la fermeture d'un flux. Si vous désirez vous assurer que les informations sont en sûreté sur le disque, utilisez \fBfsync\fP(2) (mais des considérations matérielles entrent en jeu à ce moment). .SS "Processus multithreadés et close()" .\" Date: Tue, 4 Sep 2007 13:57:35 +0200 .\" From: Fredrik Noring .\" One such race involves signals and ERESTARTSYS. If a file descriptor .\" in use by a system call is closed and then reused by, e.g., an .\" independent open() in some unrelated thread, before the original system .\" call has restarted after ERESTARTSYS, the original system call will .\" later restart with the reused file descriptor. This is most likely a .\" serious programming error. Il est probablement imprudent de fermer des descripteurs de fichier alors qu'ils peuvent peut\-être être utilisés par des appels système dans d'autres threads du même processus. Puisqu'un descripteur de fichier peut être réutilisé, il y a des conditions de concurrence obscures qui peuvent provoquer des effets de bord non désirés. .P Par ailleurs, imaginez un scénario où deux threads effectuent plusieurs opérations sur le même descripteur de fichier : .IP (1) 5 Un thread est bloqué dans un appel système E/S sur le descripteur de fichier. Par exemple, il essaie de \fBwrite\fP(2) dans un tube déjà plein ou de \fBread\fP(2) depuis le socket d'un flux qui n'a pas de données disponibles actuellement. .IP (2) Un autre thread ferme le descripteur de fichier. .P Dans cette situation, le comportement varie selon les systèmes. Sur certains, quand le descripteur de fichier est fermé, l'appel système qui bloque renvoie immédiatement une erreur. .P .\" 'struct file' in kernel-speak .\" Sur Linux (et probablement d'autres systèmes), le comportement est différent : l'appel système E/S bloquant conserve une référence à la description du fichier ouvert sous\-jacent et celle\-ci garde la description ouverte jusqu'à ce que l'appel système E/S se termine (voir \fBopen\fP(2) pour un point sur les descriptions de fichiers ouverts). Ainsi, l'appel système bloquant du premier thread peut se terminer avec succès après le \fBclose\fP() du deuxième thread. .SS "Gérer les erreurs renvoyées par close()" Un programmeur prudent vérifiera le code de retour de \fBclose\fP(), car il est possible qu'une erreur correspondant à un appel \fBwrite\fP(2) antérieur ne soit rapportée que lors du \fBclose\fP() final. Ne pas vérifier le code de retour lorsqu’un fichier est fermé peut conduire à une perte \fBsilencieuse\fP de données. Cela est principalement vrai dans le cas de systèmes de fichiers NFS, ou avec l'utilisation des quotas de disques. .P Remarquez cependant que la valeur de retour ne devrait être utilisée que pour les diagnostics (à savoir pour prévenir une application qu'il peut rester des E/S en attente ou échouées) ou de correction (comme pour écrire un fichier une ou plusieurs fois ou pour créer une sauvegarde). .P .\" The file descriptor is released early in close(); .\" close() ==> __close_fd(): .\" __put_unused_fd() ==> __clear_open_fd() .\" return filp_close(file, files); .\" .\" The errors are returned by filp_close() after the FD has been .\" cleared for re-use. .\" filp_close() Réessayer \fBclose\fP() après un renvoi d'échec n'est pas la bonne manière de faire, car il peut en résulter que le descripteur d'un fichier qui serait réutilisé à partir d'un autre thread se ferme. Cela est possible car le noyau Linux abandonne \fItoujours\fP tôt le descripteur de fichier lors d'une opération de fermeture, ce qui le libère pour être réutilisé ; les étapes de renvoi d'erreur telles que l'effacement des données sur le système de fichiers ou le périphérique arrivent plus tard dans l'opération de fermeture. .P .\" FreeBSD documents this explicitly. From the look of the source code .\" SVR4, ancient SunOS, later Solaris, and AIX all do this. Many other implementations similarly always close the file descriptor (except in the case of \fBEBADF\fP, meaning that the file descriptor was invalid) even if they subsequently report an error on return from \fBclose\fP(). POSIX.1\-2008 was silent on this point. .P Un programmeur prudent qui veut savoir les erreurs E/S doit faire précéder \fBclose\fP() d'un appel \fBfsync\fP(2). .P The \fBEINTR\fP error is a somewhat special case. Regarding the \fBEINTR\fP error, POSIX.1\-2008 said: .P .RS If \fBclose\fP() is interrupted by a signal that is to be caught, it shall return \-1 with \fIerrno\fP set to \fBEINTR\fP and the state of \fIfd\fP is unspecified. .RE .P This permits the behavior that occurs on Linux and many other implementations, where, as with other errors that may be reported by \fBclose\fP(), the file descriptor is guaranteed to be closed. However, it also permits another possibility: that the implementation returns an \fBEINTR\fP error and keeps the file descriptor open. (According to its documentation, HP\-UX's \fBclose\fP() does this.) The caller must then once more use \fBclose\fP() to close the file descriptor, to avoid file descriptor leaks. This divergence in implementation behaviors provides a difficult hurdle for portable applications, since on many implementations, \fBclose\fP() must not be called again after an \fBEINTR\fP error, and on at least one, \fBclose\fP() must be called again. .P POSIX.1\-2024 standardized the behavior of HP\-UX, making Linux and many other implementations non\-conforming. There are no plans to change the behavior on Linux. .SH "VOIR AUSSI" \fBclose_range\fP(2), \fBfcntl\fP(2), \fBfsync\fP(2), \fBopen\fP(2), \fBshutdown\fP(2), \fBunlink\fP(2), \fBfclose\fP(3) .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 .