close(2) System Calls Manual close(2) NOM close - Fermer un descripteur de fichier BIBLIOTHEQUE Bibliotheque C standard (libc, -lc) SYNOPSIS #include int close(int fd); DESCRIPTION close() ferme le descripteur de fichier fd, de maniere a ce qu'il ne reference plus aucun fichier, et puisse etre reutilise. Tous les verrouillages (consultez fcntl(2)) sur le fichier qui lui etait associe, appartenant au processus, sont supprimes quel que soit le descripteur de fichier qui fut utilise pour obtenir le verrouillage. Cela a quelques consequences malheureuses il convient d'etre extremement prudent lors de l'utilisation de verrouillages d'enregistrements cooperatifs. Voir fcntl(2) pour une discussion sur les risques et consequences et sur l'utilisation (probablement preferable) des verrouillages de description de fichier ouvert. Si fd est le dernier descripteur de fichier qui se refere a une description de fichier ouvert sous-jacente (consultez open(2)), les ressources associees a la description de fichier ouvert sont liberees. Si le descripteur etait la derniere reference sur un fichier supprime avec unlink(2), le fichier est effectivement efface. VALEUR RENVOYEE Si elle reussit, la fonction close() renvoie zero. En cas d'erreur, elle renvoie -1 et elle remplit errno pour indiquer l'erreur. ERREURS EBADF Le descripteur de fichier fd est invalide. EINTR L'appel systeme close() a ete interrompu par un signal ; consultez signal(7). EIO Une erreur d'entree-sortie s'est produite. ENOSPC EDQUOT Sur NFS, ces erreurs ne sont en principe pas signalees lors de la premiere ecriture qui depasse l'espace de stockage disponible, mais lors d'un write(2), fsync(2) ou close() consecutif. Voir les NOTES pour un point sur la raison pour laquelle close() ne devrait pas reessayer apres une erreur. STANDARDS POSIX.1-2008. HISTORIQUE POSIX.1-2001, SVr4, 4.3BSD. NOTES Une fermeture sans erreur ne garantit pas que les donnees ont ete vraiment ecrites sur le disque, car le noyau repousse les ecritures le plus tard possible. Il n'est pas frequent qu'un systeme de fichiers vide les tampons des la fermeture d'un flux. Si vous desirez vous assurer que les informations sont en surete sur le disque, utilisez fsync(2) (mais des considerations materielles entrent en jeu a ce moment). L'attribut de descripteur de fichier close-on-exec peut etre utilise pour s'assurer qu'un descripteur de fichier est ferme automatiquement en cas de succes de execve(2) ; voir fcntl(2) pour des details. Processus multithreades et close() Il est probablement imprudent de fermer des descripteurs de fichier alors qu'ils peuvent peut-etre etre utilises par des appels systeme dans d'autres threads du meme processus. Puisqu'un descripteur de fichier peut etre reutilise, il y a des conditions de concurrence obscures qui peuvent provoquer des effets de bord non desires. Par ailleurs, imaginez un scenario ou deux threads effectuent plusieurs operations sur le meme descripteur de fichier : (1) Un thread est bloque dans un appel systeme E/S sur le descripteur de fichier. Par exemple, il essaie de write(2) dans un tube deja plein ou de read(2) depuis le socket d'un flux qui n'a pas de donnees disponibles actuellement. (2) Un autre thread ferme le descripteur de fichier. Dans cette situation, le comportement varie selon les systemes. Sur certains, quand le descripteur de fichier est ferme, l'appel systeme qui bloque renvoie immediatement une erreur. Sur Linux (et probablement d'autres systemes), le comportement est different : l'appel systeme E/S bloquant conserve une reference a la description du fichier ouvert sous-jacent et celle-ci garde la description ouverte jusqu'a ce que l'appel systeme E/S se termine (voir open(2) pour un point sur les descriptions de fichiers ouverts). Ainsi, l'appel systeme bloquant du premier thread peut se terminer avec succes apres le close() du deuxieme thread. Gerer les erreurs renvoyees par close() Un programmeur prudent verifiera le code de retour de close(), car il est possible qu'une erreur correspondant a un appel write(2) anterieur ne soit rapportee que lors du close() final. Ne pas verifier le code de retour lorsqu'un fichier est ferme peut conduire a une perte silencieuse de donnees. Cela est principalement vrai dans le cas de systemes de fichiers NFS, ou avec l'utilisation des quotas de disques. Remarquez cependant que la valeur de retour ne devrait etre utilisee que pour les diagnostics (a savoir pour prevenir une application qu'il peut rester des E/S en attente ou echouees) ou de correction (comme pour ecrire un fichier une ou plusieurs fois ou pour creer une sauvegarde). Reessayer close() apres un renvoi d'echec n'est pas la bonne maniere de faire, car il peut en resulter que le descripteur d'un fichier qui serait reutilise a partir d'un autre thread se ferme. Cela est possible car le noyau Linux abandonne toujours tot le descripteur de fichier lors d'une operation de fermeture, ce qui le libere pour etre reutilise ; les etapes de renvoi d'erreur telles que l'effacement des donnees sur le systeme de fichiers ou le peripherique arrivent plus tard dans l'operation de fermeture. De meme, beaucoup d'autres implementations ferment toujours le descripteur de fichier (sauf en cas de EBADF, qui signifie que le descripteur de fichier n'etait pas valable), meme si elles signalent ensuite une erreur renvoyee par close(). POSIX.1 ne dit rien aujourd'hui sur ce point mais ce comportement sera rendu obligatoire dans la prochaine version majeure du standard. Un programmeur prudent qui veut savoir les erreurs E/S doit faire preceder close() d'un appel fsync(2). L'erreur EINTR est un cas un peu particulier. Concernant l'erreur EINTR, POSIX.1-2008 dit : Si close() est interrompu par un signal qui doit etre recupere, il renverra -1 et positionnera errno sur EINTR et l'etat de fildes ne sera pas specifie. Cela autorise un comportement qui arrive sur Linux et beaucoup d'autres implementations, ou, comme pour beaucoup d'erreurs pouvant etre signalees par close(), le descripteur de fichier se fermera assurement. Neanmoins, cela permet aussi une autre possibilite : l'implementation renvoie une erreur EINTR et laisse le descripteur de fichier ouvert (selon sa documentation, le close() de HP-UX fait cela). L'appelant doit donc utiliser une fois de plus close() pour fermer le descripteur de fichier, afin d'eviter des fuites du descripteur de fichier. Cette divergence de comportements dans l'implementation apporte un obstacle difficile a la portabilite des applications car sur beaucoup d'implementations, close() ne doit pas etre rappele apres une erreur EINTR, tandis que sur au moins une d'elles, close() doit etre rappele. Il est envisage de s'occuper de ce casse-tete dans la prochaine version majeure du standard POSIX.1. VOIR AUSSI close_range(2), fcntl(2), fsync(2), open(2), shutdown(2), unlink(2), fclose(3) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot et Jean-Philippe MENGUAL Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.06 31 octobre 2023 close(2)