.\" -*- coding: UTF-8 -*- .\" 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 "17 mai 2025" "Pagini de manual de Linux 6.15" .SH NUME close \- închide un descriptor de fișier .SH BIBLIOTECA Biblioteca C standard (\fIlibc\fP, \fI\-lc\fP) .SH SINOPSIS .nf \fB#include \fP .P \fBint close(int \fP\fIfd\fP\fB);\fP .fi .SH DESCRIERE \fBclose\fP() închide un descriptor de fișier, astfel încât acesta să nu se mai refere la niciun fișier și să poată fi reutilizat. Orice blocare de înregistrare (a se vedea \fBfcntl\fP(2)) deținută pe fișierul cu care a fost asociată și deținută de proces este eliminată, indiferent de descriptorul de fișier care a fost utilizat pentru obținerea blocării. Acest lucru are unele consecințe nefericite și trebuie să fiți foarte atenți atunci când utilizați blocarea înregistrării consultative. A se vedea \fBfcntl\fP(2) pentru discutarea riscurilor și consecințelor, precum și pentru blocajele de descriere a fișierului deschis (probabil preferate). .P Dacă \fIfd\fP este ultimul descriptor de fișier care se referă la descrierea fișierului deschis subiacent (a se vedea \fBopen\fP(2)), resursele asociate descrierii fișierului deschis sunt eliberate; dacă descriptorul de fișier a fost ultima referință la un fișier care a fost eliminat utilizând \fBunlink\fP(2), fișierul este șters. .SH "VALOAREA RETURNATĂ" \fBclose\fP() returnează zero în caz de succes. În caz de eroare, este returnat \-1, iar \fIerrno\fP este configurată pentru a indica eroarea. .SH ERORI\-IEȘIRE .TP \fBEBADF\fP \fIfd\fP nu este un descriptor de fișier deschis valid. .TP \fBEINTR\fP .\" Though, it's in doubt whether this error can ever occur; see .\" https://lwn.net/Articles/576478/ "Returning EINTR from close()" Apelul \fBclose\fP() a fost întrerupt de un semnal; consultați \fBsignal\fP(7). .TP \fBEIO\fP A apărut o eroare de In/Ieș. .TP \fBENOSPC\fP .TQ \fBEDQUOT\fP Pe NFS, aceste erori nu sunt în mod normal raportate la prima scriere care depășește spațiul de stocare disponibil, ci la o scriere ulterioară \fBwrite\fP(2), \fBfsync\fP(2) sau \fBclose\fP(). .P Consultați secțiunea NOTE pentru o discuție a motivului pentru care \fBclose\fP() nu ar trebui să fie reapelat după o eroare. .SH STANDARDE POSIX.1\-2008. .SH ISTORIC .\" SVr4 documents an additional ENOLINK error condition. POSIX.1\-2001, SVr4, 4.3BSD. .SH NOTE O închidere reușită nu garantează că datele au fost salvate cu succes pe disc, deoarece nucleul utilizează memoria cache pentru a amâna scrierile. De obicei, sistemele de fișiere nu curăță tampoanele atunci când un fișier este închis. Dacă trebuie să fiți siguri că datele sunt stocate fizic pe discul de bază, utilizați \fBfsync\fP(2); (aceasta va depinde de hardware\-ul discului în acest moment). .P .\" Fanionul de descriptor de fișier close\-on\-exec poate fi utilizat pentru a se asigura că un descriptor de fișier este închis automat în urma unui \fBexecve\fP(2) reușit; consultați \fBfcntl\fP(2) pentru detalii. .SS "Procesele cu mai multe fire de execuție și 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. Probabil că nu este înțelept să închideți descriptorii de fișier în timp ce aceștia pot fi utilizați de apeluri de sistem în alte fire de execuție din același proces. Deoarece un descriptor de fișier poate fi reutilizat, există unele condiții de concurență ascunse care pot provoca efecte secundare neintenționate. .P În plus, luați în considerare următorul scenariu în care două fire efectuează operații pe același descriptor de fișier: .IP (1) 5 Un fir este blocat într\-un apel de sistem I/O pe descriptorul de fișier. De exemplu, încearcă să efectueze \fBwrite\fP(2) pe o conductă care este deja plină sau încearcă să efectueze \fBread\fP(2) de la un soclu de flux care nu are în prezent date disponibile. .IP (2) Un alt fir închide descriptorul de fișier. .P Comportamentul în această situație variază de la un sistem la altul. Pe unele sisteme, atunci când descriptorul de fișier este închis, apelul de sistem blocant returnează imediat cu o eroare. .P .\" 'struct file' in kernel-speak .\" Pe Linux (și posibil pe alte sisteme), comportamentul este diferit: apelul de sistem I/O blocant deține o referință la descrierea fișierului deschis, iar această referință menține descrierea deschisă până la finalizarea apelului de sistem I/O. (Consultați \fBopen\fP(2) pentru o discuție despre descrierile de fișiere deschise). Astfel, apelul de sistem blocant din primul fir poate fi finalizat cu succes după efectuarea \fBclose\fP() din al doilea fir. .SS "Gestionarea răspunsurilor eronate de la close()" Un programator atent va verifica valoarea de returnare a \fBclose\fP(), deoarece este foarte posibil ca erorile de la o operație anterioară \fBwrite\fP(2) să fie raportate numai la \fBclose\fP() final care eliberează descrierea fișierului deschis. Ne verificarea valorii de returnare la închiderea unui fișier poate duce la pierderea \fIsilențioasă\fP de date. Acest lucru poate fi observat în special cu NFS și cu cota de disc. .P Rețineți, totuși, că o returnare în caz de eșec ar trebui utilizată numai în scopuri de diagnosticare (de exemplu, un avertisment adresat aplicației că este posibil să mai existe operații I/O în așteptare sau că este posibil să fi existat operații I/O eșuate) sau în scopuri de remediere (de exemplu, scrierea fișierului încă o dată sau crearea unei copii de rezervă). .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() Reîncercarea operației \fBclose\fP() după un eșec este un lucru greșit de făcut, deoarece acest lucru poate cauza închiderea unui descriptor de fișier reutilizat de la un alt fir de execuție. Acest lucru se poate întâmpla deoarece nucleul Linux eliberează \fIîntotdeauna\fP descriptorul de fișier la începutul operației de închidere, eliberându\-l pentru reutilizare; pașii care pot returna o eroare, cum ar fi trimiterea datelor către sistemul de fișiere sau dispozitiv, au loc doar mai târziu în operația de închidere. .P .\" FreeBSD documents this explicitly. From the look of the source code .\" SVR4, ancient SunOS, later Solaris, and AIX all do this. .\" Issue 8 În mod similar, multe alte implementări închid întotdeauna descriptorul de fișier (cu excepția cazului \fBEBADF\fP, ceea ce înseamnă că descriptorul de fișier a fost nevalid) chiar dacă ulterior raportează o eroare la returnarea de la operația \fBclose\fP(). În prezent, POSIX.1 nu se referă la acest aspect, dar există planuri de a impune acest comportament în următoarea versiune majoră a standardului. .P Un programator atent care dorește să știe despre erorile I/O poate precede \fBclose\fP() cu un apel la \fBfsync\fP(2). .P Eroarea \fBEINTR\fP este un caz oarecum special. În ceea ce privește eroarea \fBEINTR\fP, POSIX.1\-2008 spune: .P .RS Dacă \fBclose\fP() este întrerupt de un semnal care trebuie captat, acesta returnează \-1 cu \fIerrno\fP configurată la \fBEINTR\fP și starea lui \fIfildes\fP este nespecificată. .RE .P .\" 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 Acest lucru permite comportamentul care apare pe Linux și în multe alte implementări, unde, ca și în cazul altor erori care pot fi raportate de \fBclose\fP(), descriptorul de fișier este garantat a fi închis. Cu toate acestea, aceasta permite și o altă posibilitate: ca implementarea să returneze o eroare \fBEINTR\fP și să mențină descriptorul de fișier deschis. Conform documentației sale, \fBclose\fP() de la HP\-UX face acest lucru. Apelantul trebuie apoi să utilizeze încă o dată \fBclose\fP() pentru a închide descriptorul de fișier, pentru a evita scurgerile de informații din descriptorul de fișier. Această divergență în comportamentele de implementare reprezintă un obstacol dificil pentru aplicațiile portabile, deoarece în multe implementări, \fBclose\fP() nu trebuie să fie apelat din nou după o eroare \fBEINTR\fP, iar în cel puțin una, \fBclose\fP() trebuie să fie apelat din nou. Există planuri de rezolvare a acestei enigme pentru următoarea versiune majoră a standardului POSIX.1. .SH "CONSULTAȚI ȘI" \fBclose_range\fP(2), \fBfcntl\fP(2), \fBfsync\fP(2), \fBopen\fP(2), \fBshutdown\fP(2), \fBunlink\fP(2), \fBfclose\fP(3) .PP .SH TRADUCERE Traducerea în limba română a acestui manual a fost făcută de Remus-Gabriel Chelu . .PP Această traducere este documentație gratuită; citiți .UR https://www.gnu.org/licenses/gpl-3.0.html Licența publică generală GNU Versiunea 3 .UE sau o versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă NICIO RESPONSABILITATE. .PP Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la .MT translation-team-ro@lists.sourceforge.net .ME .