.\" -*- 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 .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" 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 "2 maja 2024 r." "Linux man\-pages 6.9.1" .SH NAZWA close \- zamyka deskryptor pliku .SH BIBLIOTEKA Standardowa biblioteka C (\fIlibc\fP, \fI\-lc\fP) .SH SKŁADNIA .nf \fB#include \fP .P \fBint close(int \fP\fIfd\fP\fB);\fP .fi .SH OPIS \fBclose\fP() zamyka deskryptor pliku, tak że nie odnosi się on już później do żadnego pliku i może być użyty ponownie. Wszelkie blokady na poziomie rekordu (zob. \fBfcntl\fP(2)) utrzymywane na pliku, z którymi deskryptor był związany, i których właścicielem był proces, zostają usunięte, niezależnie od deskryptora plików, którego użyto dla uzyskanie blokady. Ma to pewne niefortunne skutki, dlatego należy być szczególnie ostrożnym przy używaniu pomocniczego zakładania blokad na poziomie rekordów. W podręczniku \fBfcntl\fP(2) opisano ryzyka i konsekwencje oraz (prawdopodobnie preferowane) blokady opisu otwartego pliku (ang. open file description (OFD) lock). .P Jeśli \fIfd\fP jest ostatnim deskryptorem pliku odnoszącego się do podległego opisu otwartego pliku (OFD, zob. \fBopen\fP(2)), to zasoby związane z opisem otwartego pliku zostają zwolnione; jeśli deskryptor pliku był ostatnim odniesieniem do pliku, który usunięto za pomocą polecenia \fBunlink\fP(2), to plik jest kasowany. .SH "WARTOŚĆ ZWRACANA" \fBclose\fP() w przypadku powodzenia zwraca zero. W razie wystąpienia błędu zwracane jest \-1 i ustawiana jest zmienna \fIerrno\fP wskazując na błąd. .SH BŁĘDY .TP \fBEBADF\fP \fIfd\fP nie jest prawidłowym deskryptorem otwartego pliku. .TP \fBEINTR\fP .\" Though, it's in doubt whether this error can ever occur; see .\" https://lwn.net/Articles/576478/ "Returning EINTR from close()" Funkcja \fBclose\fP() została przerwana przez sygnał; zobacz \fBsignal\fP(7). .TP \fBEIO\fP Wystąpił błąd wejścia/wyjścia. .TP \fBENOSPC\fP .TQ \fBEDQUOT\fP W NFS, błędy te nie są zwykle zgłaszane wobec wobec pierwszego zapisu, który przekroczył dostępną przestrzeń dyskową, lecz wobec kolejnego \fBwrite\fP(2), \fBfsync\fP(2) lub \fBclose\fP(). .P Zob. UWAGI, aby dowiedzieć się dlaczego \fBclose\fP() nie powinien być powtarzany po wystąpieniu błędu. .SH STANDARDY POSIX.1\-2008. .SH HISTORIA .\" SVr4 documents an additional ENOLINK error condition. POSIX.1\-2001, SVr4, 4.3BSD. .SH UWAGI Pomyślne zamknięcie nie gwarantuje, że dane zostaną pomyślnie zapisane na dysku, gdyż jądro używa bufora do opóźnienia zapisów. Zwykle systemy plików nie opróżniają buforów przy zamykaniu pliku. Jeśli istnieje potrzeba zapewnienia, aby dane zostały zapisane fizycznie na nośniku, należy użyć \fBfsync\fP(2) (zapis zależy w tym momencie od właściwości sprzętowych dysku). .P .\" Znacznik deskryptora pliku zamknij\-przy\-wykonaniu może być użyty do upewnienia się, że dany deskryptor pliku jest automatycznie zamknięty po pomyślnym \fBexecve\fP(2); więcej szczegółów w podręczniku \fBfcntl\fP(2). .SS "Procesy wielowątkowe 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. Prawdopodobnie nie jest roztropnie zamykać deskryptory pliku w chwili, gdy mogą być one używane przez wywołania systemowe w innych wątkach tego samego procesu. Ponieważ deskryptora pliku można użyć ponownie, istnieją pewne zawiłe sytuacje hazardu, które mogą przynieść pewnie nieprzewidziane skutku uboczne. .P Co więcej, proszę rozważyć następujący scenariusz, gdy dwa wątki przeprowadzają operacje na tym samym deskryptorze pliku: .IP (1) 5 Jeden wątek jest zablokowany w wywołaniu wejścia/wyjścia na deskryptorze pliku. Może to być na przykład próba \fBwrite\fP(2) do zapełnionego potoku lub próba \fBread\fP(2) z gniazda strumieniowego, które aktualnie nie dysponuje danymi. .IP (2) Inny wątek zamyka deskryptor pliku. .P Zachowanie w takiej sytuacji różni się w różnych systemach. W niektórych, po zamknięciu deskryptora pliku, blokujące wywołanie systemowe natychmiast powróci z błędem. .P .\" 'struct file' in kernel-speak .\" W Linuksie (i prawdopodobnie w niektórych innych systemach) zachowanie jest inne: blokujące wywołanie systemowe wejścia/wyjścia utrzymuje referencję do podległego opisu otwartego pliku (OFD) i to odniesienie utrzymuje opis otwarty do momentu zakończenia wywołania systemowego wejścia/wyjścia (zob. \fBopen\fP(2) aby dowiedzieć się więcej o opisach otwartego pliku). Z tego względu, blokujące wywołanie systemowe w pierwszym wątku może się pomyślnie zakończyć po \fBclose\fP() w drugim wątku. .SS "Zajmowanie się błędami zwróconymi przez close()" Ostrożny programista sprawdzi wartość zwracaną przez \fBclose\fP(), ponieważ może się zdarzyć, że błędy wcześniejszej operacji \fBwrite\fP(2) zostaną zgłoszone jedynie przy kończącym \fBclose\fP(), zwalniającym opis otwartego pliku (OFD). Niesprawdzenie zwróconej podczas zamykania pliku wartości może doprowadzić do \fIniesygnalizowanej\fP utraty danych. Jest to obserwowane zwłaszcza w przypadku NFS i przy używaniu przydziałów dyskowych. .P Proszę jednak zauważyć, że zwrócenie błędu powinno być używane jedynie do celów diagnostycznych (tj. jako ostrzeżenie dla aplikacji, że wciąż może istnieć oczekujące wejście/wyjście lub wejście/wyjście mogło się nie powieść) lub do celów zaradczych (np. ponowny zapis pliku lub utworzenie kopii). .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() Ponowna próba wykonania \fBclose\fP() po zwróceniu błędu nie jest właściwym zachowaniem, ponieważ może to spowodować zamknięcie użytego ponownie deskryptora pliku z innego wątku. Może się tak zdarzyć, ponieważ jądro Linux \fIzawsze\fP uwalnia deskryptor plików wcześnie przy operacji zamykania, zwalniając go do ponownego użytku; kroki mogące zwrócić błąd, takie jak opróżnianie danych do systemu plików lub urządzenia, mogą wystąpić przy operacji zamykania jedynie później. .P .\" FreeBSD documents this explicitly. From the look of the source code .\" SVR4, ancient SunOS, later Solaris, and AIX all do this. .\" Issue 8 Większość innych implementacji zachowuje się podobnie zamykając deskryptor plików zawsze (z wyjątkiem \fBEBADF\fP oznaczającego, że deskryptor pliku był nieprawidłowy) nawet, gdy następnie zwrócą błąd przy powrocie z \fBclose\fP(). POSIX.1 nie wypowiada się obecnie na ten temat, ale istnieją plany nakazania tego zachowania w następnym głównym wydaniu standardu .P Ostrożny programista, chcący posiąść informacje o błędach wejścia/wyjścia, może poprzedzić \fBclose\fP() wywołaniem do \fBfsync\fP(2). .P Błąd \fBEINTR\fP jest poniekąd szczególnym przypadkiem. Odnośnie błędu \fBEINTR\fP norma POSIX.1\-2008 wspomina: .P .RS Jeśli \fBclose\fP() zostanie przerwane mającym być przechwyconym sygnałem, ma zwrócić wartość \-1 z \fIerrno\fP ustawionym na \fBEINTR\fP, a stan \fIfildes\fP jest nieokreślony. .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 Zezwala to na zachowanie występujące w Linuksie i wielu innych implementacjach, gdzie, jak w przypadku innych błędów, jakie może zwrócić \fBclose\fP(), deskryptor pliku zostanie na pewno zamknięty. Istnieje jednak również inna możliwość: że implementacja zwróci błąd \fBEINTR\fP i utrzyma otwarty deskryptor pliku (zgodnie z dokumentacją HP\-UX, jego \fBclose\fP() tak czyni). Wywołujący musi wówczas użyć \fBclose\fP() ponownie, aby zamknąć deskryptor pliku i aby uniknąć wycieku deskryptora pliku. Ta rozbieżność w implementacji czyni trudności przenośnym aplikacjom, ponieważ w wielu implementacjach \fBclose\fP() nie musi być ponownie wywoływane po błędzie \fBEINTR\fP, a w przynajmniej jednej, \fBclose\fP() musi być ponownie wywołane. Istnieją plany rozwiązania tej zagwozdki w następnym głównym wydaniu standardu POSIX.1. .SH "ZOBACZ TAKŻE" \fBclose_range\fP(2), \fBfcntl\fP(2), \fBfsync\fP(2), \fBopen\fP(2), \fBshutdown\fP(2), \fBunlink\fP(2), \fBfclose\fP(3) .PP .SH TŁUMACZENIE Tłumaczenie niniejszej strony podręcznika: Przemek Borys , Andrzej Krzysztofowicz i Michał Kułach . .PP Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License w wersji 3 .UE lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI. .PP Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej .MT manpages-pl-list@lists.sourceforge.net .ME .