close(2)                      System Calls Manual                     close(2)

NUME
       close - inchide un descriptor de fi<?>ier

BIBLIOTECA
       Biblioteca C standard (libc, -lc)

SINOPSIS
       #include <unistd.h>

       int close(int fd);

DESCRIERE
       close() inchide un descriptor de fi<?>ier, astfel incat acesta sa nu se
       mai refere la niciun fi<?>ier <?>i sa poata fi reutilizat. Orice
       blocare de inregistrare (a se vedea fcntl(2)) de<?>inuta pe fi<?>ierul
       cu care a fost asociata <?>i de<?>inuta de proces este eliminata,
       indiferent de descriptorul de fi<?>ier care a fost utilizat pentru
       ob<?>inerea blocarii. Acest lucru are unele consecin<?>e nefericite
       <?>i trebuie sa fi<?>i foarte aten<?>i atunci cand utiliza<?>i blocarea
       inregistrarii consultative.  A se vedea fcntl(2) pentru discutarea
       riscurilor <?>i consecin<?>elor, precum <?>i pentru blocajele de
       descriere a fi<?>ierului deschis (probabil preferate).

       Daca fd este ultimul descriptor de fi<?>ier care se refera la
       descrierea fi<?>ierului deschis subiacent (a se vedea open(2)),
       resursele asociate descrierii fi<?>ierului deschis sunt eliberate; daca
       descriptorul de fi<?>ier a fost ultima referin<?>a la un fi<?>ier care
       a fost eliminat utilizand unlink(2), fi<?>ierul este <?>ters.

VALOAREA RETURNATA
       close() returneaza zero in caz de succes. In caz de eroare, este
       returnat -1, iar errno este configurata pentru a indica eroarea.

ERORI-IE<?>IRE
       EBADF  fd nu este un descriptor de fi<?>ier deschis valid.

       EINTR  Apelul close() a fost intrerupt de un semnal; consulta<?>i
              signal(7).

       EIO    A aparut o eroare de In/Ie<?>.

       ENOSPC
       EDQUOT Pe NFS, aceste erori nu sunt in mod normal raportate la prima
              scriere care depa<?>e<?>te spa<?>iul de stocare disponibil, ci
              la o scriere ulterioara write(2), fsync(2) sau close().

       Consulta<?>i sec<?>iunea NOTE pentru o discu<?>ie a motivului pentru
       care close() nu ar trebui sa fie reapelat dupa o eroare.

STANDARDE
       POSIX.1-2008.

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

NOTE
       O inchidere reu<?>ita nu garanteaza ca datele au fost salvate cu succes
       pe disc, deoarece nucleul utilizeaza memoria cache pentru a amana
       scrierile. De obicei, sistemele de fi<?>iere nu cura<?>a tampoanele
       atunci cand un fi<?>ier este inchis. Daca trebuie sa fi<?>i siguri ca
       datele sunt stocate fizic pe discul de baza, utiliza<?>i fsync(2);
       (aceasta va depinde de hardware-ul discului in acest moment).

       Fanionul de descriptor de fi<?>ier close-on-exec poate fi utilizat
       pentru a se asigura ca un descriptor de fi<?>ier este inchis automat in
       urma unui execve(2) reu<?>it; consulta<?>i fcntl(2) pentru detalii.

   Procesele cu mai multe fire de execu<?>ie <?>i close()
       Probabil ca nu este in<?>elept sa inchide<?>i descriptorii de fi<?>ier
       in timp ce ace<?>tia pot fi utiliza<?>i de apeluri de sistem in alte
       fire de execu<?>ie din acela<?>i proces. Deoarece un descriptor de
       fi<?>ier poate fi reutilizat, exista unele condi<?>ii de concuren<?>a
       ascunse care pot provoca efecte secundare neinten<?>ionate.

       In plus, lua<?>i in considerare urmatorul scenariu in care doua fire
       efectueaza opera<?>ii pe acela<?>i descriptor de fi<?>ier:

       (1)  Un fir este blocat intr-un apel de sistem I/O pe descriptorul de
            fi<?>ier. De exemplu, incearca sa efectueze write(2) pe o conducta
            care este deja plina sau incearca sa efectueze read(2) de la un
            soclu de flux care nu are in prezent date disponibile.

       (2)  Un alt fir inchide descriptorul de fi<?>ier.

       Comportamentul in aceasta situa<?>ie variaza de la un sistem la altul.
       Pe unele sisteme, atunci cand descriptorul de fi<?>ier este inchis,
       apelul de sistem blocant returneaza imediat cu o eroare.

       Pe Linux (<?>i posibil pe alte sisteme), comportamentul este diferit:
       apelul de sistem I/O blocant de<?>ine o referin<?>a la descrierea
       fi<?>ierului deschis, iar aceasta referin<?>a men<?>ine descrierea
       deschisa pana la finalizarea apelului de sistem I/O. (Consulta<?>i
       open(2) pentru o discu<?>ie despre descrierile de fi<?>iere deschise).
       Astfel, apelul de sistem blocant din primul fir poate fi finalizat cu
       succes dupa efectuarea close() din al doilea fir.

   Gestionarea raspunsurilor eronate de la close()
       Un programator atent va verifica valoarea de returnare a close(),
       deoarece este foarte posibil ca erorile de la o opera<?>ie anterioara
       write(2) sa fie raportate numai la close() final care elibereaza
       descrierea fi<?>ierului deschis. Ne verificarea valorii de returnare la
       inchiderea unui fi<?>ier poate duce la pierderea silen<?>ioasa de date.
       Acest lucru poate fi observat in special cu NFS <?>i cu cota de disc.

       Re<?>ine<?>i, totu<?>i, ca o returnare in caz de e<?>ec ar trebui
       utilizata numai in scopuri de diagnosticare (de exemplu, un avertisment
       adresat aplica<?>iei ca este posibil sa mai existe opera<?>ii I/O in
       a<?>teptare sau ca este posibil sa fi existat opera<?>ii I/O e<?>uate)
       sau in scopuri de remediere (de exemplu, scrierea fi<?>ierului inca o
       data sau crearea unei copii de rezerva).

       Reincercarea opera<?>iei close() dupa un e<?>ec este un lucru gre<?>it
       de facut, deoarece acest lucru poate cauza inchiderea unui descriptor
       de fi<?>ier reutilizat de la un alt fir de execu<?>ie. Acest lucru se
       poate intampla deoarece nucleul Linux elibereaza intotdeauna
       descriptorul de fi<?>ier la inceputul opera<?>iei de inchidere,
       eliberandu-l pentru reutilizare; pa<?>ii care pot returna o eroare, cum
       ar fi trimiterea datelor catre sistemul de fi<?>iere sau dispozitiv, au
       loc doar mai tarziu in opera<?>ia de inchidere.

       In mod similar, multe alte implementari inchid intotdeauna descriptorul
       de fi<?>ier (cu excep<?>ia cazului EBADF, ceea ce inseamna ca
       descriptorul de fi<?>ier a fost nevalid) chiar daca ulterior raporteaza
       o eroare la returnarea de la opera<?>ia close(). In prezent, POSIX.1 nu
       se refera la acest aspect, dar exista planuri de a impune acest
       comportament in urmatoarea versiune majora a standardului.

       Un programator atent care dore<?>te sa <?>tie despre erorile I/O poate
       precede close() cu un apel la fsync(2).

       Eroarea EINTR este un caz oarecum special. In ceea ce prive<?>te
       eroarea EINTR, POSIX.1-2008 spune:

              Daca close() este intrerupt de un semnal care trebuie captat,
              acesta returneaza -1 cu errno configurata la EINTR <?>i starea
              lui fildes este nespecificata.

       Acest lucru permite comportamentul care apare pe Linux <?>i in multe
       alte implementari, unde, ca <?>i in cazul altor erori care pot fi
       raportate de close(), descriptorul de fi<?>ier este garantat a fi
       inchis. Cu toate acestea, aceasta permite <?>i o alta posibilitate: ca
       implementarea sa returneze o eroare EINTR <?>i sa men<?>ina
       descriptorul de fi<?>ier deschis. Conform documenta<?>iei sale, close()
       de la HP-UX face acest lucru. Apelantul trebuie apoi sa utilizeze inca
       o data close() pentru a inchide descriptorul de fi<?>ier, pentru a
       evita scurgerile de informa<?>ii din descriptorul de fi<?>ier. Aceasta
       divergen<?>a in comportamentele de implementare reprezinta un obstacol
       dificil pentru aplica<?>iile portabile, deoarece in multe implementari,
       close() nu trebuie sa fie apelat din nou dupa o eroare EINTR, iar in
       cel pu<?>in una, close() trebuie sa fie apelat din nou. Exista planuri
       de rezolvare a acestei enigme pentru urmatoarea versiune majora a
       standardului POSIX.1.

CONSULTA<?>I <?>I
       close_range(2), fcntl(2), fsync(2), open(2), shutdown(2), unlink(2),
       fclose(3)

TRADUCERE
       Traducerea in limba romana a acestui manual a fost facuta de Remus-
       Gabriel Chelu <remusgabriel.chelu@disroot.org>

       Aceasta traducere este documenta<?>ie gratuita; citi<?>i Licen<?>a
       publica generala GNU Versiunea 3
       <https://www.gnu.org/licenses/gpl-3.0.html> sau o versiune ulterioara
       cu privire la condi<?>ii privind drepturile de autor.  NU se asuma
       NICIO RESPONSABILITATE.

       Daca gasi<?>i erori in traducerea acestui manual, va rugam sa
       trimite<?>i un e-mail la <translation-team-ro@lists.sourceforge.net>.

Pagini de manual de Linux 6.15    17 mai 2025                         close(2)