Provided by: manpages-fr-dev_4.18.1-1_all bug

NOM

       close - Fermer un descripteur de fichier

BIBLIOTHÈQUE

       Bibliothèque C standard (libc, -lc)

SYNOPSIS

       #include <unistd.h>

       int close(int fd);

DESCRIPTION

       close()  ferme le descripteur de fichier fd, de manière à ce qu'il ne référence plus aucun
       fichier, et puisse être réutilisé. Tous les  verrouillages  (consultez  fcntl(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).

       Si fd est le dernier descripteur de fichier qui se réfère à  une  description  de  fichier
       ouvert  sous-jacente  (consultez  open(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 unlink(2), le fichier est effectivement effacé.

VALEUR RENVOYÉE

       Si  elle  réussit,  la  fonction close() renvoie zéro. 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 système close() a été interrompu par un signal ; consultez signal(7).

       EIO    Une erreur d'entrée-sortie s'est produite.

       ENOSPC, EDQUOT
              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 write(2), fsync(2) ou
              close() consécutif.

       Voir les NOTES pour un point sur la raison pour laquelle close() ne devrait pas  réessayer
       après une erreur.

STANDARDS

       POSIX.1-2001, POSIX.1-2008, SVr4, 4.3BSD.

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  fsync(2)  (mais
       des considérations matérielles entrent en jeu à ce moment).

       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  execve(2) ;  voir
       fcntl(2) pour des détails.

   Processus multithreadés et close()
       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.

       Par ailleurs, imaginez un scénario où deux threads effectuent plusieurs opérations sur  le
       même descripteur de fichier :

       (1)  Un  thread  est  bloqué  dans un appel système E/S sur le descripteur de fichier. Par
            exemple, il essaie de write(2) dans un tube déjà plein ou de read(2) depuis le socket
            d'un flux qui n'a pas de données disponibles actuellement.

       (2)  Un autre thread ferme le descripteur de fichier.

       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.

       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 open(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 close() du
       deuxième thread.

   Gérer les erreurs renvoyées par close()
       Un programmeur prudent vérifiera le code de retour de close(), car il est possible  qu'une
       erreur  correspondant  à un appel write(2) antérieur ne soit rapportée que lors du close()
       final. Ne pas vérifier le code de retour lorsqu’un fichier est fermé peut conduire  à  une
       perte  silencieuse  de  données.  Cela  est principalement vrai dans le cas de systèmes de
       fichiers NFS, ou avec l'utilisation des quotas de disques.

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

       Réessayer close() 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  toujours 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.

       De même, beaucoup d'autres implémentations ferment  toujours  le  descripteur  de  fichier
       (sauf  en  cas  de EBADF, qui signifie que le descripteur de fichier n'était pas valable),
       même si elles signalent ensuite une erreur renvoyée  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  précéder  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 être récupéré, il renverra  -1  et
              positionnera errno sur EINTR et l'état de fildes ne sera pas spécifié.

       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 close(),  le  descripteur  de
       fichier  se  fermera  assurément.  Néanmoins,  cela  permet  aussi une autre possibilité :
       l'implémentation 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'é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,
       close()  ne  doit  pas  être  rappelé  après une erreur EINTR, tandis que sur au moins une
       d'elles, close() doit être rappelé. Il est envisagé de s'occuper de ce casse-tête 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  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⟩.