.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson. .\" and Copyright (C) 2016 Michael Kerrisk .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" Modified Wed Jul 21 22:40:25 1993 by Rik Faith .\" Modified Sat Feb 18 15:27:48 1995 by Michael Haardt .\" Modified Sun Apr 14 11:40:50 1996 by Andries Brouwer : .\" corrected description of effect on locks (thanks to .\" Tigran Aivazian ). .\" Modified Fri Jan 31 16:21:46 1997 by Eric S. Raymond .\" Modified 2000-07-22 by Nicolás Lichtmaier .\" added note about close(2) not guaranteeing that data is safe on close. .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH CLOSE 2 "9 juin 2020" Linux "Manuel du programmeur Linux" .SH NOM close \- Fermer un descripteur de fichier .SH SYNOPSIS .nf \fB#include \fP .PP \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). .PP 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 remplit \fIerrno\fP avec le code d'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, \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. .PP Voir les NOTES pour un point sur la raison pour laquelle \fBclose\fP() ne devrait pas réessayer après une erreur. .SH CONFORMITÉ .\" SVr4 documents an additional ENOLINK error condition. POSIX.1\-2001, POSIX.1\-2008, SVr4, 4.3BSD. .SH NOTES 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). .PP .\" 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. .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. .PP Par ailleurs, imaginez un scénario où deux threads effectuent plusieurs opérations sur le même descripteur de fichier\ : .IP 1. 3 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. .PP 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. .PP .\" '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. .PP 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). .PP .\" 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. .PP .\" FreeBSD documents this explicitly. From the look of the source code .\" SVR4, ancient SunOS, later Solaris, and AIX all do this. .\" Issue 8 De même, beaucoup d'autres implémentations ferment toujours le descripteur de fichier (sauf en cas de \fBEBADF\fP, qui signifie que le descripteur de fichier n'était pas valable), même si elles signalent ensuite une erreur renvoyée par \fBclose\fP(). POSIX.1 ne dit rien aujourd'hui sur ce point mais ce comportement sera rendu obligatoire dans la prochaine version majeure du standard. .PP Un programmeur prudent qui veut savoir les erreurs E/S doit faire précéder \fBclose\fP() d'un appel \fBfsync\fP(2). .PP L'erreur \fBEINTR\fP est un cas un peu particulier. Concernant l'erreur \fBEINTR\fP, POSIX.1\-2008 dit\ : .PP .RS Si \fBclose\fP() est interrompu par un signal qui doit être récupéré, il renverra \fB\-1\fP et positionnera \fIerrno\fP sur \fBEINTR\fP et l'état de \fIfildes\fP ne sera pas spécifié. .RE .PP .\" FIXME . for later review when Issue 8 is one day released... .\" POSIX proposes further changes for EINTR .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8 .\" http://austingroupbugs.net/view.php?id=529 .\" .\" FIXME . .\" Review the following glibc bug later .\" https://sourceware.org/bugzilla/show_bug.cgi?id=14627 Cela autorise un comportement qui arrive sur Linux et beaucoup d'autres implémentations, où, comme pour beaucoup d'erreurs pouvant être signalées par \fBclose\fP(), le descripteur de fichier se fermera assurément. Néanmoins, cela permet aussi une autre possibilité\ : l'implémentation renvoie une erreur \fBEINTR\fP et laisse le descripteur de fichier ouvert (selon sa documentation, le \fBclose\fP() de HP\-UX fait cela). L'appelant doit donc utiliser une fois de plus \fBclose\fP() pour fermer le descripteur de fichier, afin d'éviter des fuites du descripteur de fichier. Cette divergence de comportements dans l'implémentation apporte un obstacle difficile à la portabilité des applications car sur beaucoup d'implémentations, \fBclose\fP() ne doit pas être rappelé après une erreur \fBEINTR\fP, tandis que sur au moins une d'elles, \fBclose\fP() doit être rappelé. Il est envisagé de s'occuper de ce casse\-tête dans la prochaine version majeure du standard POSIX.1. .SH "VOIR AUSSI" \fBfcntl\fP(2), \fBfsync\fP(2), \fBopen\fP(2), \fBshutdown\fP(2), \fBunlink\fP(2), \fBfclose\fP(3) .SH COLOPHON Cette page fait partie de la publication\ 5.10 du projet \fIman\-pages\fP 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/. .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 . 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. 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 .