.\" -*- 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 <mtk.manpages@gmail.com>
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" Modified Wed Jul 21 22:40:25 1993 by Rik Faith <faith@cs.unc.edu>
.\" Modified Sat Feb 18 15:27:48 1995 by Michael Haardt
.\" Modified Sun Apr 14 11:40:50 1996 by Andries Brouwer <aeb@cwi.nl>:
.\"   corrected description of effect on locks (thanks to
.\"   Tigran Aivazian <tigran@sco.com>).
.\" Modified Fri Jan 31 16:21:46 1997 by Eric S. Raymond <esr@thyrsus.com>
.\" Modified 2000-07-22 by Nicolás Lichtmaier <nick@debian.org>
.\"   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 <unistd.h>\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 <noring@nocrew.org>
.\" 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
Autorami polskiego tłumaczenia niniejszej strony podręcznika są:
Przemek Borys <pborys@dione.ids.pl>,
Andrzej Krzysztofowicz <ankry@green.mf.pg.gda.pl>
i
Michał Kułach <michal.kulach@gmail.com>
.
.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 .
