.\" -*- coding: UTF-8 -*-
.\" This manpage is Copyright (C) 1992 Drew Eckhardt;
.\" and Copyright (C) 1993 Michael Haardt, Ian Jackson.
.\" and Copyright (C) 2008 Greg Banks
.\" and Copyright (C) 2006, 2008, 2013, 2014 Michael Kerrisk <mtk.manpages@gmail.com>
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" Modified 1993-07-21 by Rik Faith <faith@cs.unc.edu>
.\" Modified 1994-08-21 by Michael Haardt
.\" Modified 1996-04-13 by Andries Brouwer <aeb@cwi.nl>
.\" Modified 1996-05-13 by Thomas Koenig
.\" Modified 1996-12-20 by Michael Haardt
.\" Modified 1999-02-19 by Andries Brouwer <aeb@cwi.nl>
.\" Modified 1998-11-28 by Joseph S. Myers <jsm28@hermes.cam.ac.uk>
.\" Modified 1999-06-03 by Michael Haardt
.\" Modified 2002-05-07 by Michael Kerrisk <mtk.manpages@gmail.com>
.\" Modified 2004-06-23 by Michael Kerrisk <mtk.manpages@gmail.com>
.\" 2004-12-08, mtk, reordered flags list alphabetically
.\" 2004-12-08, Martin Pool <mbp@sourcefrog.net> (& mtk), added O_NOATIME
.\" 2007-09-18, mtk, Added description of O_CLOEXEC + other minor edits
.\" 2008-01-03, mtk, with input from Trond Myklebust
.\"     <trond.myklebust@fys.uio.no> and Timo Sirainen <tss@iki.fi>
.\"     Rewrite description of O_EXCL.
.\" 2008-01-11, Greg Banks <gnb@melbourne.sgi.com>: add more detail
.\"     on O_DIRECT.
.\" 2008-02-26, Michael Haardt: Reorganized text for O_CREAT and mode
.\"
.\" FIXME . Apr 08: The next POSIX revision has O_EXEC, O_SEARCH, and
.\" O_TTYINIT.  Eventually these may need to be documented.  --mtk
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH open 2 "2 maja 2024 r." "Linux man\-pages 6.9.1" 
.SH NAZWA
open, creat \- otwiera i ewentualnie tworzy plik
.SH BIBLIOTEKA
Standardowa biblioteka C (\fIlibc\fP, \fI\-lc\fP)
.SH SKŁADNIA
.nf
\fB#include <fcntl.h>\fP
.P
\fBint open(const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB, ...\fP
\fB           \fP/*\fB mode_t \fP\fImode\fP\fB \fP*/\fB );\fP
.P
\fBint creat(const char *\fP\fIpathname\fP\fB, mode_t \fP\fImode\fP\fB);\fP
.P
\fBint openat(int \fP\fIdirfd\fP\fB, const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB, ...\fP
\fB           \fP/*\fB mode_t \fP\fImode\fP\fB \fP*/\fB );\fP
.P
/* Udokumentowane oddzielnie, w \fBopenat2\fP(2):
\& */
\fBint openat2(int \fP\fIdirfd\fP\fB, const char *\fP\fIpathname\fP\fB,\fP
\fB           const struct open_how *\fP\fIhow\fP\fB, size_t \fP\fIsize\fP\fB);\fP
.fi
.P
.RS -4
Wymagane ustawienia makr biblioteki glibc (patrz \fBfeature_test_macros\fP(7)):
.RE
.P
\fBopenat\fP():
.nf
    Od glibc 2.10:
        _POSIX_C_SOURCE >= 200809L
    Przed glibc 2.10:
        _ATFILE_SOURCE
.fi
.SH OPIS
Wywołanie systemowe \fBopen\fP() otwiera plik określony ścieżką
\fIpathname\fP. Jeśli podany plik nie istnieje, może być opcjonalnie (jeśli we
\fIflags\fP podano \fBO_CREAT\fP) utworzony przez \fBopen\fP().
.P
Wartością zwracaną przez \fBopen\fP() jest deskryptor pliku: niewielka,
całkowita liczba nieujemna, będąca indeksem wpisu w tablicy otwartych
deskryptorów plików procesu. Deskryptor pliku jest używany w kolejnych
wywołaniach systemowych (\fBread\fP(2), \fBwrite\fP(2), \fBlseek\fP(2), \fBfcntl\fP(2)
itp.), w celu odniesienia się do otwartego pliku. Deskryptor pliku zwracany
przez pomyślne wywołanie będzie najniższym numerem deskryptora pliku, który
nie jest aktualnie otwarty przez proces.
.P
Domyślnie, nowy deskryptor pliku jest ustawiany jako pozostający otwarty po
wykonaniu przez \fBexecve\fP(2)  (tj. znacznik deskryptora pliku \fBFD_CLOEXEC\fP
opisany w \fBfcntl\fP(2) jest początkowo wyłączony); można użyć opisanego
poniżej znacznika \fBO_CLOEXEC\fP aby zmienić to zachowanie. Przesunięcie pliku
jest ustawiane na początek pliku (zob. \fBlseek\fP(2)).
.P
Wywołanie \fBopen\fP() tworzy nowy \fIopis otwartego pliku\fP, wpis w systemowej
tablicy otwartych plików. Opis otwartego pliku zawiera przesunięcie pliku i
znaczniki statusu pliku (zob. niżej). Deskryptor pliku odnosi się do opisu
otwartego pliku i na to odniesienie nie ma wpływu późniejsze usunięcie
ścieżki \fIpathname\fP lub jej modyfikacja, w celu wskazania innego
pliku. Więcej informacji o opisach otwartego pliku zawarto w rozdziale
UWAGI.
.P
Argument \fIflags\fP musi zawierać jeden z następujących \fItrybów dostępu\fP:
\fBO_RDONLY\fP, \fBO_WRONLY\fP lub \fBO_RDWR\fP. Stanowią one, odpowiednio, żądania
otwarcia tylko do odczytu, tylko do zapisu, lub do odczytu i zapisu.
.P
.\" SUSv4 divides the flags into:
.\" * Access mode
.\" * File creation
.\" * File status
.\" * Other (O_CLOEXEC, O_DIRECTORY, O_NOFOLLOW)
.\" though it's not clear what the difference between "other" and
.\" "File creation" flags is.  I raised an Aardvark to see if this
.\" can be clarified in SUSv4; 10 Oct 2008.
.\" http://thread.gmane.org/gmane.comp.standards.posix.austin.general/64/focus=67
.\" TC1 (balloted in 2013), resolved this, so that those three constants
.\" are also categorized" as file status flags.
.\"
Ponadto, we \fIflags\fP może zsumować bitowo (OR) zero lub więcej znaczników
tworzenia pliku i znaczników statusu pliku. \fIZnaczniki tworzenia pliku\fP to:
\fBO_CLOEXEC\fP, \fBO_CREAT\fP, \fBO_DIRECTORY\fP, \fBO_EXCL\fP, \fBO_NOCTTY\fP,
\fBO_NOFOLLOW\fP, \fBO_TMPFILE\fP i \fBO_TRUNC\fP. \fIZnaczniki statusu pliku\fP to
wszystkie pozostałe znaczniki, wypisane poniżej. Rozróżnieniem pomiędzy tymi
dwoma grupami znaczników jest fakt, że znaczniki tworzenia pliku wpływają na
zachowanie samej operacji otwarcia, natomiast znaczniki statusu pliku
wpływają na zachowanie kolejnych operacji wejścia/wyjścia. Znaczniki statusu
pliku można pobrać i (w niektórych przypadkach) zmodyfikować; więcej
szczegółów w podręczniku \fBfcntl\fP(2).
.P
Oto pełna lista znaczników tworzenia pliku i znaczników statusu pliku:
.TP 
\fBO_APPEND\fP
Plik jest otwierany w trybie dopisywania. Przed każdą operacją \fBwrite\fP(2),
przesunięcie pliku jest ustawiane na koniec pliku, jak z
\fBlseek\fP(2). Modyfikacja przesunięcia pliku i operacja zapisu jest
przeprowadzana jako jeden, niepodzielny krok.
.IP
.\" For more background, see
.\" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453946
.\" http://nfs.sourceforge.net/
\fBO_APPEND\fP może prowadzić do uszkodzenia plików na systemach plików NFS,
gdy więcej niż jeden proces naraz dopisuje dane do pliku. Jest to związane z
faktem, że NFS nie obsługuje dopisywania do pliku, więc jądro klienta musi
to zasymulować, co nie może zostać wykonane bez wyścigu.
.TP 
\fBO_ASYNC\fP
Włącza wejście/wyjście sterowane sygnałem: generuje sygnał (domyślnie
\fBSIGIO\fP, ale można go zmienić za pomocą \fBfcntl\fP(2)), gdy wejście lub
wyjście poprzez ten deskryptor pliku staje się możliwe. Ta funkcja jest
dostępna jedynie dla terminali, pseudoterminali, gniazd i (od Linuksa 2.6)
potoków oraz FIFO. Więcej szczegółów można znaleźć w podręczniku
\fBfcntl\fP(2). Zob. też USTERKI poniżej.
.TP 
\fBO_CLOEXEC\fP (od Linuksa 2.6.23)
.\" NOTE! several other man pages refer to this text
.\" FIXME . for later review when Issue 8 is one day released...
.\" POSIX proposes to fix many APIs that provide hidden FDs
.\" http://austingroupbugs.net/tag_view_page.php?tag_id=8
.\" http://austingroupbugs.net/view.php?id=368
Włącza znacznik zamknięcia\-przy\-wykonaniu dla nowego deskryptora
pliku. Podanie tego znacznika umożliwia uniknięcie przez program wykonywania
dodatkowych operacji \fBF_SETFD\fP \fBfcntl\fP(2) w celu ustawienia znacznika
\fBFD_CLOEXEC\fP.
.IP
.\" This flag fixes only one form of the race condition;
.\" The race can also occur with, for example, file descriptors
.\" returned by accept(), pipe(), etc.
Proszę zauważyć, że korzystanie z tego znacznika jest niezbędne w niektórych
programach wielowątkowych, ponieważ oddzielna operacja \fBF_SETFD\fP
\fBfcntl\fP(2), ustawiająca znacznik \fBFD_CLOEXEC\fP, nie zapobiega wystąpieniu
sytuacji wyścigu, gdy jeden wątek otwiera deskryptor pliku, próbując ustawić
swój znacznik zamknięcia\-przy\-wykonaniu za pomocą \fBfcntl\fP(2), a w tym samym
czasie inny wątek dokonuje \fBfork\fP(2) oraz \fBexecve\fP(2). W zależności od
kolejności wykonania, wyścig ten może spowodować nieoczekiwany wyciek
deskryptora pliku zwróconego przez \fBopen\fP(), do programu wykonywanego przez
proces potomny utworzony przez \fBfork\fP(2) (jest to typ wyścigu, który jest
teoretycznie możliwy dla każdego wywołania systemowego tworzącego deskryptor
pliku, który powinien otrzymać znacznik zamknięcia\-przy\-wykonaniu, dlatego
różne inne linuksowe wywołania systemowe udostępniają równoważnik znacznika
\fBO_CLOEXEC\fP, aby poradzić sobie z tym problemem).
.TP 
\fBO_CREAT\fP
Jeśli \fIpathname\fP nie istnieje, tworzy ją jako zwykły plik.
.IP
Właściciel (identyfikator użytkownika) nowego pliku jest ustawiany na
efektywny identyfikator użytkownika procesu.
.IP
.\" As at Linux 2.6.25, bsdgroups is supported by ext2, ext3, ext4, and
.\" XFS (since Linux 2.6.14).
Własność grupy (identyfikator grupy) nowego pliku jest ustawiana na
efektywny identyfikator grupy procesu (zachowanie Systemu\ V) lub na
identyfikator grupy katalogu nadrzędnego (zachowanie BSD). W Linuksie, wybór
typu zachowania zależy od ustawienia bitu trybu set\-group\-ID w katalogu
nadrzędnym: jeśli bit ten jest ustawiony, wybierane jest zachowanie BSD; w
przeciwnym razie, stosowane jest zachowanie Systemu\ V. W przypadku
niektórych systemów plików, zachowanie to zależy również od opcji montowania
\fIbsdgroups\fP i \fIsysvgroups\fP, które opisano w podręczniku \fBmount\fP(8).
.IP
Argument \fImode\fP określa bity trybu pliku, jakie mają być zastosowane do
nowo tworzonego pliku. Jeśli nie poda się \fBO_CREAT\fP ani \fBO_TMPFILE\fP we
\fIflags\fP, to \fImode\fP jest ignorowane (można je zatem podać jako 0 lub po
prostu pominąć). Argument \fImode\fP \fBmusi\fP być określony, jeśli we \fIflags\fP
podano \fBO_CREAT\fP lub \fBO_TMPFILE\fP; jeśli się go nie poda, jako tryb pliku
zostaną użyte jakieś losowe bajty ze stosu.
.IP
Efektywny tryb jest modyfikowany przez \fIumask\fP procesu, w zwykły sposób:
pod nieobecność domyślnych list kontroli dostępu (ACL), trybem tworzonego
pliku jest \fI(mode\ &\ \[ti]umask)\fP.
.IP
Proszę zauważyć, że \fImode\fP stosuje się tylko do kolejnych dostępów do nowo
tworzonego pliku; wywołanie \fBopen\fP(), które tworzy plik tylko do odczytu,
może zwrócić również deskryptor pliku do odczytu i do zapisu.
.IP
Dla parametru \fImode\fP udostępniono następujące stałe symboliczne:
.RS
.TP  9
\fBS_IRWXU\fP
00700 użytkownik (właściciel pliku) ma prawa odczytu, zapisu i uruchamiania.
.TP 
\fBS_IRUSR\fP
00400 użytkownik ma prawa odczytu.
.TP 
\fBS_IWUSR\fP
00200 użytkownik ma prawa zapisu.
.TP 
\fBS_IXUSR\fP
00100 użytkownik ma prawa uruchamiania.
.TP 
\fBS_IRWXG\fP
00070 grupa ma prawa odczytu, zapisu i uruchamiania.
.TP 
\fBS_IRGRP\fP
00040 grupa ma prawa odczytu.
.TP 
\fBS_IWGRP\fP
00020 grupa ma prawa zapisu.
.TP 
\fBS_IXGRP\fP
00010 grupa ma prawa uruchamiania.
.TP 
\fBS_IRWXO\fP
00007 inni mają prawa odczytu, zapisu i uruchamiania.
.TP 
\fBS_IROTH\fP
00004 inni mają prawa odczytu.
.TP 
\fBS_IWOTH\fP
00002 inni mają prawa zapisu.
.TP 
\fBS_IXOTH\fP
00001 inni mają prawa uruchamiania.
.RE
.IP
Zgodnie z POSIX, wpływ ustawienia innych bitów w \fImode\fP jest
nieokreślony. W Linuksie, honorowane jest również ustawienie następujących
bitów w \fImode\fP:
.RS
.TP  9
\fBS_ISUID\fP
0004000 bit set\-user\-ID
.TP 
\fBS_ISGID\fP
0002000 bit set\-group\-ID (zob. \fBinode\fP(7)).
.TP 
\fBS_ISVTX\fP
0001000 bit lepkości (zob. \fBinode\fP(7)).
.RE
.TP 
\fBO_DIRECT\fP (od Linuksa 2.4.10)
Powoduje próbę zminimalizowania efektów związanych z buforowaniem
wejścia/wyjścia do i z tego pliku. Na ogół spowoduje to zmniejszenie
wydajności, ale jest to przydatne w specyficznych sytuacjach, na przykład
gdy aplikacje buforują we własnym zakresie. Wejście/wyjście dla pliku odbywa
się wówczas bezpośrednio z/do buforów w przestrzeni użytkownika. Sam
znacznik \fBO_DIRECT\fP stara się dokonywać transferu synchronicznie, ale nie
daje gwarancji znacznika \fBO_SYNC\fP, że dane i wymagane metadane są
transferowane. Aby zagwarantować synchroniczne wejście/wyjście, oprócz
\fBO_DIRECT\fP konieczne jest użycie również \fBO_SYNC\fP. Więcej informacji w
rozdziale UWAGI poniżej.
.IP
Semantycznie podobny (lecz przestarzały) interfejs dla urządzeń blokowych
opisano w \fBraw\fP(8).
.TP 
\fBO_DIRECTORY\fP
.\" But see the following and its replies:
.\" http://marc.theaimsgroup.com/?t=112748702800001&r=1&w=2
.\" [PATCH] open: O_DIRECTORY and O_CREAT together should fail
.\" O_DIRECTORY | O_CREAT causes O_DIRECTORY to be ignored.
Jeśli \fIpathname\fP nie jest katalogiem, spowoduje niepowodzenie otwarcia. Ten
znacznik dodano w Linuksie 2.1.126, aby uniknąć problemów blokowania usług
(DoS), gdy \fBopendir\fP(3) jest wywołane dla FIFO lub dla urządzenia
taśmowego.
.TP 
\fBO_DSYNC\fP
Operacje zapisu pliku zakończą się zgodnie z wymaganiem kompletności
zsynchronizowanego wejścia/wyjścia \fIdanych\fP w sposób gwarantujący spójność.
.IP
W chwili powrotu \fBwrite\fP(2) (i podobnego), dane wyjściowe zostały już
przeniesione na właściwe urządzenie, razem ze wszystkimi metadanymi pliku,
które są konieczne do pobrania tych danych (tzn. jest to równoważne jak
gdyby po każdym \fBwrite\fP(2) wywoływać \fBfdatasync\fP(2)). \fIProszę zapoznać się z UWAGAMI poniżej\fP.
.TP 
\fBO_EXCL\fP
Zapewnia, że to wywołanie utworzy plik: jeśli znacznik poda się razem z
\fBO_CREAT\fP, a ścieżka \fIpathname\fP już istnieje, to \fBopen\fP() zawiedzie z
błędem \fBEEXIST\fP.
.IP
.\" POSIX.1-2001 explicitly requires this behavior.
Po podaniu obu tych znaczników, nie podąża się za dowiązaniami
symbolicznymi: jeśli \fIpathname\fP jest dowiązaniem symbolicznym, to \fBopen\fP()
zawiedzie niezależnie od tego, na co wskazuje to dowiązanie symboliczne.
.IP
Co do zasady, zachowanie \fBO_EXCL\fP jest niezdefiniowane, jeśli użyje się go
bez \fBO_CREAT\fP. Jest jeden wyjątek: w Linuksie 2.6 i późniejszych, \fBO_EXCL\fP
można użyć bez \fBO_CREAT\fP jeśli \fIpathname\fP odnosi się do urządzenia
blokowego. Jeśli urządzenie blokowe jest w użyciu przez system (np. jest
zamontowane), to \fBopen\fP() zawiedzie z błędem \fBEBUSY\fP.
.IP
W systemie plików NFS \fBO_EXCL\fP jest obsługiwane tylko w NFSv3 lub
późniejszym na jądrze 2.6 lub późniejszym. W środowiskach NFS, gdzie nie
zapewniono obsługi \fBO_EXCL\fP, programy które polegają na nim, w celu
dokonywania zadań blokowania, będą prowadziły do wyścigu. Przenośne
programy, które chcą przeprowadzać niepodzielne blokowanie pliku za pomocą
pliku\-blokady i muszą unikać polegania na obsłudze \fBO_EXCL\fP w NFS, mogą
tworzyć unikalny plik na tym samym systemie plików (np. wykorzystując nazwę
stacji i PID) i używać \fBlink\fP(2) do utworzenia dowiązania do
pliku\-blokady. Jeśli \fBlink\fP(2) zwróci 0, to utworzenie blokady się
powiodło. W przeciwnym razie, należy użyć \fBstat\fP(2) na unikalnym pliku, aby
sprawdzić, czy ilość jego dowiązań wzrosła do 2. W takiej sytuacji
utworzenie blokady również się powiodło.
.TP 
\fBO_LARGEFILE\fP
(LFS)  Pozwala na otwarcie plików, których rozmiarów nie można przedstawić w
\fIoff_t\fP (lecz można w \fIoff64_t\fP). Konieczne jest zdefiniowanie makra
\fB_LARGEFILE64_SOURCE\fP (przed włączeniem \fIjakichkolwiek\fP plików
nagłówkowych) aby uzyskać jego definicję. Ustawienie makra sprawdzania cech
\fB_FILE_OFFSET_BITS\fP na 64 (zamiast na \fBO_LARGEFILE\fP) jest preferowaną
metodą uzyskiwania dostępu do dużych plików w systemach 32\-bitowych
(zob. \fBfeature_test_macros\fP(7)).
.TP 
\fBO_NOATIME\fP (od Linuksa 2.6.8)
Nie aktualizuje czasu ostatniego dostępu do pliku (\fIst_atime\fP w i\-węźle)
gdy plik jest odczytywany (\fBread\fP(2)).
.IP
Znacznik ten można użyć tylko, jeśli spełniony zostanie jeden z poniższych
warunków:
.RS
.IP \[bu] 3
.\" Strictly speaking: the filesystem UID
Efektywny UID procesu jest zgodny z UID\-em właściciela pliku.
.IP \[bu]
Proces wywołujący ma przywilej \fBCAP_FOWNER\fP (ang. capability) w swojej
przestrzeni nazw użytkownika, a UID właściciela pliku ma przypisanie do tej
przestrzeni nazw.
.RE
.IP
.\" The O_NOATIME flag also affects the treatment of st_atime
.\" by mmap() and readdir(2), MTK, Dec 04.
Znacznik ten jest przeznaczony dla programów indeksujących lub tworzących
kopie zapasowe, gdzie pozwala na znaczną redukcję aktywności dysku. Znacznik
ten może nie działać we wszystkich systemach plików. Jednym z przykładów
jest NFS, gdzie to serwer zarządza czasami dostępu.
.TP 
\fBO_NOCTTY\fP
Jeśli \fIpathname\fP odnosi się do urządzenia terminalowego \[em]
zob. \fBtty\fP(4) \[em] to nie stanie się terminalem sterującym procesu, nawet
jeśli proces takiego nie ma.
.TP 
\fBO_NOFOLLOW\fP
Jeśli końcowa składowa (basename) ścieżki \fIpathname\fP jest dowiązaniem
symbolicznym, to otwarcie zawiedzie z błędem \fBELOOP\fP. Dowiązania
symboliczne wcześniejszych składowych ścieżki wciąż zostaną rozwinięte
(proszę zauważyć, że błąd \fBELOOP\fP, który może się zdarzyć w tym przypadku,
jest nierozróżnialny od sytuacji, gdy otwarcie zawiedzie, z powodu zbyt
wielu dowiązań symbolicznych, które wystąpiły przy rozwiązywaniu
wcześniejszych składowych ścieżki).
.IP
Znacznik ten jest rozszerzeniem FreeBSD, który został dodany w Linuksie
2.1.126 i został później wprowadzony jako standard w normie POSIX.1\-2008.
.IP
.\" The headers from glibc 2.0.100 and later include a
.\" definition of this flag; \fIkernels before Linux 2.1.126 will ignore it if
.\" used\fP.
Zob. też \fBO_PATH\fP poniżej.
.TP 
\fBO_NONBLOCK\fP lub \fBO_NDELAY\fP
Plik jest otwierany w trybie nieblokującym, o ile to możliwe. Ani \fBopen\fP()
ani kolejne operacje wejścia/wyjścia, na zwróconym przez to wywołanie
deskryptorze, nie spowodują blokowania procesu wywołującego.
.IP
Proszę zauważyć, że ustawienie tego znacznika nie ma wpływu na działanie
\fBpoll\fP(2), \fBselect\fP(2), \fBepoll\fP(7) i podobnych, ponieważ interfejsy te
jedynie informują wywołującego o tym, gdy deskryptor pliku jest
\[Bq]gotowy\[rq] co oznacza, że operacja wejścia/wyjścia na deskryptorze
pliku ze znacznikiem \fBO_NONBLOCK\fP \fIzdecydowanie\fP nie prowadziłaby do
zablokowania.
.IP
Proszę zauważyć, że znacznik ten nie ma wpływu na zwykłe pliki i urządzenia
blokowe tzn. operacja wejścia/wyjścia będzie (chwilowo) blokować, gdy
wymagana jest aktywność urządzenia, niezależnie od ustawienia
\fBO_NONBLOCK\fP. Ponieważ takie zachowanie \fBO_NONBLOCK\fP może w przyszłości
być zaimplementowane, aplikacje nie powinny zależeć od zachowania
blokowania, przy podawaniu tego znacznika w przypadku zwykłych plików i
urządzeń blokowych.
.IP
Szczegóły dotyczące obsługi FIFO (nazwanych potoków) można znaleźć w
podręczniku \fBfifo\fP(7). Opis wpływu znacznika \fBO_NONBLOCK\fP, w połączeniu z
blokadami obowiązującymi (przymusowymi) oraz z dzierżawami pliku, znajduje
się w podręczniku \fBfcntl\fP(2).
.TP 
\fBO_PATH\fP (od Linuksa 2.6.39)
.\" commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bd
.\" commit 326be7b484843988afe57566b627fb7a70beac56
.\" commit 65cfc6722361570bfe255698d9cd4dccaf47570d
.\"
.\" http://thread.gmane.org/gmane.linux.man/2790/focus=3496
.\"	Subject: Re: [PATCH] open(2): document O_PATH
.\"	Newsgroups: gmane.linux.man, gmane.linux.kernel
.\"
Pozyskuje deskryptor pliku, którego można użyć w dwóch celach: do wskazania
położenia w drzewie systemu plików i do przeprowadzenia operacji, które
działają na poziomie samego deskryptora pliku. Sam plik nie jest otwierany,
dlatego inne operacje plikowe (np. \fBread\fP(2), \fBwrite\fP(2), \fBfchmod\fP(2),
\fBfchown\fP(2), \fBfgetxattr\fP(2), \fBioctl\fP(2), \fBmmap\fP(2)) zawiodą z błędem
\fBEBADF\fP.
.IP
Na wynikowym deskryptorze pliku \fImożna\fP wykonać następujące operacje:
.RS
.IP \[bu] 3
\fBclose\fP(2).
.IP \[bu]
.\" commit 332a2e1244bd08b9e3ecd378028513396a004a24
\fBfchdir\fP(2), jeśli deskryptor pliku odnosi się do katalogu (od Linuksa
3.5).
.IP \[bu]
\fBfstat\fP(2) (od Linuksa 3.6).
.IP \[bu]
.\" fstat(): commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2
.\" fstatfs(): commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf
\fBfstatfs\fP(2) (od Linuksa 3.12).
.IP \[bu]
Zduplikowanie deskryptora pliku (\fBdup\fP(2), \fBF_DUPFD\fP z \fBfcntl\fP(2), itp).
.IP \[bu]
Uzyskanie i ustawienie znaczników deskryptora pliku (\fBF_GETFD\fP i \fBF_SETFD\fP
z \fBfcntl\fP(2)).
.IP \[bu]
Pobranie znaczników statusu otwartego pliku za pomocą operacji \fBF_GETFL\fP z
\fBfcntl\fP(2): zwrócone znaczniki będą obejmowały również bit \fBO_PATH\fP.
.IP \[bu]
Przekazanie deskryptora pliku jako argumentu \fIdirfd\fP do \fBopenat\fP() i
innych wywołań systemowych \[Bq]*at()\[rq]. Obejmuje to również \fBlinkat\fP(2)
z \fBAT_EMPTY_PATH\fP (lub za pomocą procfs wykorzystując \fBAT_SYMLINK_FOLLOW\fP)
nawet, gdy plik nie jest katalogiem.
.IP \[bu]
Przekazanie deskryptora pliku do innego procesu za pomocą gniazda domeny
Uniksa (zob. \fBSCM_RIGHTS\fP w podręczniku \fBunix\fP(7)).
.RE
.IP
Gdy \fBO_PATH\fP poda się we \fIflags\fP, to bity znaczników inne niż
\fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP i \fBO_NOFOLLOW\fP są ignorowane.
.IP
Otwarcie pliku lub katalogu ze znacznikiem \fBO_PATH\fP nie wymaga uprawnień do
samego obiektu (lecz wymaga uprawnienia wykonania (przeszukiwania) na
katalogach w składowej ścieżki). W zależności od kolejnej operacji, może być
wykonane sprawdzenie odpowiednich uprawnień pliku (np. \fBfchdir\fP(2) wymaga
uprawnienia wykonania (przeszukania) na katalogu, do którego odnosi się jego
argument z deskryptorem pliku). Odmiennie, przy uzyskiwaniu odniesienia do
obiektu systemu plików za pomocą znacznika \fBO_RDONLY\fP, wymagane jest
posiadanie przez wywołującego uprawnienia odczytu, nawet gdy kolejna
operacja (np. \fBfchdir\fP(2), \fBfstat\fP(2)) nie wymaga uprawnienia odczytu do
obiektu.
.IP
Jeśli \fIpathname\fP jest dowiązaniem symbolicznym i podano również znacznik
\fBO_NOFOLLOW\fP, to wywołanie zwróci deskryptor pliku odnoszący się do
dowiązania symbolicznego. Ten deskryptor pliku może służyć jako argument
\fIdirfd\fP w wywołaniach do \fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2) i
\fBreadlinkat\fP(2) z pustą ścieżką, aby wywołania działały na samym dowiązaniu
symbolicznym.
.IP
Jeśli \fIpathname\fP odnosi się do punktu automatycznego montowania, który nie
został jeszcze wyzwolony, tak więc nie zamontowano w nim innego systemu
plików, to wywołanie zwróci deskryptor pliku odnoszący się do katalogu
automatycznego montowania, bez wyzwalania montowania. Można następnie użyć
\fBfstatfs\fP(2), aby sprawdzić, czy jest to faktycznie niewyzwolony punkt
automatycznego montowania (\fB.f_type == AUTOFS_SUPER_MAGIC\fP).
.IP
Można użyć \fBO_PATH\fP w przypadku zwykłych plików, aby uzyskać funkcjonalność
równoważną \fBO_EXEC\fP z POSIX.1. Pozwala to na otwarcie pliku, do którego
posiada się uprawnienie wykonywania, ale nie posiada się uprawnienia
odczytu, a następnie wykonanie pliku, za pomocą kroków podobnych do
poniższych:
.IP
.in +4n
.EX
char buf[PATH_MAX];
fd = open("jakiś_program", O_PATH);
snprintf(buf, PATH_MAX, "/proc/self/fd/%d", fd);
execl(buf, "jakiś_program", (char *) NULL);
.EE
.in
.IP
Deskryptor pliku \fBO_PATH\fP może być również przekazany jako argument
\fBfexecve\fP(3).
.TP 
\fBO_SYNC\fP
Operacje zapisu na pliku zakończą się zgodnie z wymaganiem kompletności
zsynchronizowanego wejścia/wyjścia \fIpliku\fP w sposób gwarantujący spójność
(odmiennie od zakończenia zgodnie z wymaganiem kompletności
zsynchronizowanego wejścia/wyjścia \fIdanych\fP, udostępnianego przez
\fBO_DSYNC\fP).
.IP
W chwili powrotu \fBwrite\fP(2) (i podobnego), dane wyjściowe i powiązane
metadane pliku zostały już przeniesione na właściwe urządzenie (tzn. jest to
równoważne jak gdyby po każdym \fBwrite\fP(2) wywoływać \fBfsync\fP(2)). \fIProszę zapoznać się z UWAGAMI poniżej\fP.
.TP 
\fBO_TMPFILE\fP (od Linuksa 3.11)
.\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e
.\" commit f4e0c30c191f87851c4a53454abb55ee276f4a7e
.\" commit bb458c644a59dbba3a1fe59b27106c5e68e1c4bd
Tworzy nienazwany, zwykły plik tymczasowy. Argument \fIpathname\fP określa
katalog, w katalogu tym, w systemie plików zostanie utworzony nienazwany
i\-węzeł. Wszystko, co zostanie zapisane do wynikowego pliku, ulegnie utracie
po zamknięciu ostatniego deskryptora pliku chyba, że plik otrzyma nazwę.
.IP
Ze znacznikiem \fBO_TMPFILE\fP należy użyć \fBO_RDWR\fP lub \fBO_WRONLY\fP i,
opcjonalnie, \fBO_EXCL\fP. Jeśli nie poda się \fBO_EXCL\fP, to można skorzystać z
\fBlinkat\fP(2) do utworzenia dowiązania do systemu plików, czyniąc plik
stałym, za pomocą kodu podobnego do poniższego:
.IP
.in +4n
.EX
char path[PATH_MAX];
fd = open("/ścieżka/do/katalogu", O_TMPFILE | O_RDWR,
                        S_IRUSR | S_IWUSR);
\&
/* Wejście/wyjście na \[aq]fd\[aq]... */
\&
linkat(fd, "", AT_FDCWD, "/ścieżka/do/pliku", AT_EMPTY_PATH);
\&
/* Jeśli wywołujący nie ma przywileju CAP_DAC_READ_SEARCH
   (potrzebnego do użycia AT_EMPTY_PATH z linkat(2)),
   i system plików proc(5) jest zamontowany, to powyższe
   wywołanie linkat(2) można zastąpić przez:
\&
snprintf(path, PATH_MAX,  "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/ścieżka/do/pliku",
                        AT_SYMLINK_FOLLOW);
*/
.EE
.in
.IP
W tym przypadku argument \fImode\fP \fBopen\fP() określa tryb uprawnień pliku,
podobnie jak przy \fBO_CREAT\fP.
.IP
Podanie \fBO_EXCL\fP w połączeniu z \fBO_TMPFILE\fP zapobiega możliwości
utworzenia dowiązania do systemu plików w powyższy sposób (proszę zauważyć,
że znaczenie \fBO_EXCL\fP w tym przypadku różni się od znaczenia \fBO_EXCL\fP w
pozostałych przypadkach).
.IP
.\" Inspired by http://lwn.net/Articles/559147/
Istnieją dwa główne zastosowania \fBO_TMPFILE\fP:
.RS
.IP \[bu] 3
Usprawniona funkcjonalność \fBtmpfile\fP(3): tworzenie plików tymczasowych bez
ryzyka wystąpienia wyścigu, które: (1) są automatycznie usuwane po
zamknięciu; (2) nie da się do nich dostać za pomocą żadnej ścieżki; (3) nie
są przedmiotem ataków na dowiązania symboliczne oraz (4) nie wymagają
wymyślania przez wywołującego unikatowych nazw.
.IP \[bu]
Tworzenie plików początkowo niewidocznych, które są następnie wypełniane
danymi i dostosowywane w celu posiadania właściwych atrybutów systemu plików
(\fBfchown\fP(2), \fBfchmod\fP(2), \fBfsetxattr\fP(2) itp.) przed niepodzielnym
utworzeniem dowiązania do systemu plików, w stanie już w pełni
ukształtowanym (za pomocą opisanego wyżej \fBlinkat\fP(2)).
.RE
.IP
.\" To check for support, grep for "tmpfile" in kernel sources
.\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788
.\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe
.\" commit ef3b9af50bfa6a1f02cd7b3f5124b712b1ba3e3c
.\" commit 50732df02eefb39ab414ef655979c2c9b64ad21c
\fBO_TMPFILE\fP wymaga obsługi w podległym systemie plików; jedynie podzbiór
linuksowych systemów plików ją zapewnia. W pierwotnej implementacji, obsługę
zapewniały system plików ext2, ext3, ext4, UDF, Minix i tmpfs. Następnie
dodano obsługę kolejnych systemów plików: XFS (Linux 3.15); Btrfs (Linux
3.16); F2FS (Linux 3.16) oraz ubifs (Linux 4.9)
.TP 
\fBO_TRUNC\fP
Jeśli plik już istnieje, jest zwykłym plikiem i tryb dostępu pozwala na
zapis (tzn. jest to \fBO_RDWR\fP lub \fBO_WRONLY\fP), to plik ten zostanie obcięty
do zerowej długości. Jeśli plik to FIFO lub urządzenie terminalowe, to
znacznik \fBO_TRUNC\fP jest ignorowany. W pozostałych przypadkach efekt użycia
znacznika \fBO_TRUNC\fP jest nieokreślony.
.SS creat()
Wywołanie \fBcreat\fP() jest równoważne wywołaniu \fBopen\fP() z argumentem
\fIflags\fP ustawionym na \fBO_CREAT|O_WRONLY|O_TRUNC\fP.
.SS openat()
Wywołanie systemowe \fBopenat\fP() operuje w dokładnie taki sam sposób jak
\fBopen\fP(), z wyjątkiem różnic opisanych tutaj.
.P
Argument \fIdirfd\fP jest używany w połączeniu z argumentem \fIpathname\fP, w
następujący sposób:
.IP \[bu] 3
Jeśli ścieżka podana w \fIpathname\fP jest bezwzględna, to \fIdirfd\fP jest
ignorowane.
.IP \[bu]
Jeśli ścieżka podana w \fIpathname\fP jest względna, a \fIdirfd\fP ma wartość
specjalną \fBAT_FDCWD\fP, to \fIpathname\fP jest interpretowana względem bieżącego
katalogu roboczego procesu wywołującego (jak \fBopen\fP()).
.IP \[bu]
Jeśli ścieżka podana w \fIpathname\fP jest względna, to jest interpretowana
względem katalogu, do którego odnosi się deskryptor pliku \fIdirfd\fP (zamiast
w odniesieniu do bieżącego katalogu roboczego procesu wywołującego, jak
czyni to \fBopen\fP() w stosunku do ścieżek względnych). W tym przypadku,
\fIdirfd\fP musi być katalogiem, który był otwarty do odczytu (\fBO_RDONLY\fP) lub
za pomocą znacznika \fBO_PATH\fP.
.P
.\"
Jeśli ścieżka podana w \fIpathname\fP jest względna, a \fIdirfd\fP nie jest
prawidłowym deskryptorem pliku, to wystąpi błąd (\fBEBADF\fP; można zatem
posłużyć się tym mechanizmem do upewnienia się, że ścieżka \fIpathname\fP jest
bezwzględna, podając w \fIdirfd\fP nieprawidłowy numer deskryptora).
.SS openat2(2)
Wywołanie systemowe \fBopenat2\fP(2) jest rozszerzeniem \fBopenat\fP() i
udostępnia nadzbiór funkcji wobec \fBopenat\fP(). Jest udokumentowane
oddzielnie, w podręczniku \fBopenat2\fP(2).
.SH "WARTOŚĆ ZWRACANA"
W przypadku powodzenia, \fBopen\fP(), \fBopenat\fP() i \fBcreat\fP() zwracają nowy
deskryptor pliku (liczbę nieujemną). W razie wystąpienia błędu zwracane jest
\-1 i ustawiane \fIerrno\fP wskazując błąd.
.SH BŁĘDY
\fBopen\fP(), \fBopenat\fP() i \fBcreat\fP() mogą zawieść z powodu następujących
błędów:
.TP 
\fBEACCES\fP
Żądany dostęp do pliku nie jest dozwolony, odmówiono uprawnienia
przeszukiwania dla jednego z katalogów składowych ścieżki \fIpathname\fP, plik
jeszcze nie istnieje i nie dozwolono na dostęp do zapisu do katalogu
nadrzędnego (zob. też \fBpath_resolution\fP(7)).
.TP 
\fBEACCES\fP
.\" commit 30aba6656f61ed44cba445a3c0d38b296fa9e8f5
Gdy podano \fBO_CREAT\fP, włączona jest kontrolka systemowa sysctl
\fIprotected_fifos\fP lub \fIprotected_regular\fP, plik już istnieje i jest FIFO
lub zwykłym plikiem, właścicielem pliku nie jest ani bieżący użytkownik, ani
właściciel katalogu nadrzędnego oraz katalog nadrzędny jest zapisywalny
zarówno dla wszystkich lub dla grupy, jak i ma ustawiony bit
lepkości. Więcej szczegółów w opisach \fI/proc/sys/fs/protected_fifos\fP i
\fI/proc/sys/fs/protected_regular\fP w podręczniku \fBproc_sys_fs\fP(5).
.TP 
\fBEBADF\fP
(\fBopenat\fP())  \fIpathname\fP jest względne, lecz \fIdirfd\fP nie wynosi ani
\fBAT_FDCWD\fP, ani nie jest prawidłowym deskryptorem pliku.
.TP 
\fBEBUSY\fP
We \fIflags\fP podano \fBO_EXCL\fP, a ścieżka \fIpathname\fP odnosi się do urządzenia
blokowego, które jest w użyciu przez system (np. jest zamontowane).
.TP 
\fBEDQUOT\fP
Podano \fBO_CREAT\fP, plik nie istnieje, a przydział bloków dyskowych lub
i\-węzłów dla użytkownika w systemie plików wyczerpał się.
.TP 
\fBEEXIST\fP
\fIpathname\fP już istnieje, a użyto \fBO_CREAT\fP i \fBO_EXCL\fP.
.TP 
\fBEFAULT\fP
\fIpathname\fP wskazuje poza dostępną dla użytkownika przestrzeń adresową.
.TP 
\fBEFBIG\fP
Zob. \fBEOVERFLOW\fP.
.TP 
\fBEINTR\fP
Wywołanie zostało przerwane przez procedurę obsługi sygnału, w trakcie
zablokowania w oczekiwaniu na ukończenie otwarcia na powolnym (np. FIFO;
zob. \fBfifo\fP(7)) urządzeniu; zob. \fBsignal\fP(7).
.TP 
\fBEINVAL\fP
System plików nie obsługuje znacznika \fBO_DIRECT\fP. Więcej informacji w
\fBUWAGACH\fP.
.TP 
\fBEINVAL\fP
.\" In particular, __O_TMPFILE instead of O_TMPFILE
Nieprawidłowa wartość we \fIflags\fP.
.TP 
\fBEINVAL\fP
We \fIflags\fP podano \fBO_TMPFILE\fP, lecz nie podano \fBO_WRONLY\fP, ani \fBO_RDWR\fP.
.TP 
\fBEINVAL\fP
We \fIflags\fP podano \fBO_CREAT\fP, lecz ostatnia składowa (\[Bq]basename\[rq])
ścieżki \fIpathname\fP nowego pliku jest nieprawidłowa (np. zawiera znaki,
które nie są dozwolone w danym systemie plików).
.TP 
\fBEINVAL\fP
Ostatnia składowa (\[Bq]basename\[rq]) ścieżki \fIpathname\fP jest
nieprawidłowa (np. zawiera znaki, które nie są dozwolone w danym systemie
plików).
.TP 
\fBEISDIR\fP
\fIpathname\fP odnosi się do katalogu, a żądany był dostęp z prawem zapisu
(tzn. ustawione było \fBO_WRONLY\fP lub \fBO_RDWR\fP).
.TP 
\fBEISDIR\fP
\fIpathname\fP odnosi się do istniejącego katalogu, we \fIflags\fP podano
\fBO_TMPFILE\fP i jeden z: \fBO_WRONLY\fP lub \fBO_RDWR\fP, lecz ta wersja jądra nie
zapewnia funkcjonalności \fBO_TMPFILE\fP.
.TP 
\fBELOOP\fP
Podczas rozwiązywania \fIpathname\fP napotkano zbyt wiele dowiązań
symbolicznych.
.TP 
\fBELOOP\fP
\fIpathname\fP była dowiązaniem symbolicznym, a we \fIflags\fP podano
\fBO_NOFOLLOW\fP, lecz nie podano \fBO_PATH\fP.
.TP 
\fBEMFILE\fP
Osiągnięto limit liczby otwartych deskryptorów pliku na proces (zob. opis
\fBRLIMIT_NOFILE\fP w podręczniku \fBgetrlimit\fP(2)).
.TP 
\fBENAMETOOLONG\fP
\fIpathname\fP było zbyt długie.
.TP 
\fBENFILE\fP
Zostało osiągnięte systemowe ograniczenie na całkowitą liczbę otwartych
plików.
.TP 
\fBENODEV\fP
\fIpathname\fP odnosi się do pliku urządzenia specjalnego, a odpowiadające mu
urządzenie nie istnieje (jest to błąd w jądrze Linux; w takiej sytuacji
powinno być zwracane \fBENXIO\fP).
.TP 
\fBENOENT\fP
Nie ustawiono \fBO_CREAT\fP, a nazwany plik nie istnieje.
.TP 
\fBENOENT\fP
Składowa \fIpathname\fP, która powinna być katalogiem nie istnieje lub jest
wiszącym dowiązaniem symbolicznym.
.TP 
\fBENOENT\fP
\fIpathname\fP odnosi się do nieistniejącego katalogu, we \fIflags\fP podano
\fBO_TMPFILE\fP i jeden z: \fBO_WRONLY\fP lub \fBO_RDWR\fP, lecz ta wersja jądra nie
zapewnia funkcjonalności \fBO_TMPFILE\fP.
.TP 
\fBENOMEM\fP
Nazwany plik jest FIFO, lecz nie można przydzielić pamięci dla bufora FIFO,
ponieważ osiągnięto bezwzględny limit pamięci przydzielanej potokom na
użytkownika, a wywołujący nie jest uprzywilejowany; zob. \fBpipe\fP(7).
.TP 
\fBENOMEM\fP
Brak pamięci jądra.
.TP 
\fBENOSPC\fP
Gdy \fIpathname\fP miało być utworzone, okazało się, że na urządzeniu na którym
miało się znajdować brak miejsca na nowy plik.
.TP 
\fBENOTDIR\fP
Składowa użyta w \fIpathname\fP jako katalog w rzeczywistości nie jest
katalogiem lub podano \fBO_DIRECTORY\fP, a \fIpathname\fP nie było katalogiem.
.TP 
\fBENOTDIR\fP
(\fBopenat\fP())  \fIpathname\fP jest ścieżką względną a \fIdirfd\fP jest
deskryptorem pliku odnoszącym się do pliku zamiast do katalogu.
.TP 
\fBENXIO\fP
Podano \fBO_NONBLOCK\fP | \fBO_WRONLY\fP, plik o zadanej nazwie stanowi FIFO i nie
jest ono otwarte dla żadnego procesu do odczytu.
.TP 
\fBENXIO\fP
Plik jest specjalnym plikiem urządzenia, a odpowiadające mu urządzenie nie
istnieje.
.TP 
\fBENXIO\fP
Plik jest gniazdem domeny Uniksa.
.TP 
\fBEOPNOTSUPP\fP
System plików zawierający \fIpathname\fP nie obsługuje \fBO_TMPFILE\fP.
.TP 
\fBEOVERFLOW\fP
.\" See http://bugzilla.kernel.org/show_bug.cgi?id=7253
.\" "Open of a large file on 32-bit fails with EFBIG, should be EOVERFLOW"
.\" Reported 2006-10-03
Ścieżka \fIpathname\fP odnosi się do zwykłego pliku, który jest zbyt duży, aby
móc go otworzyć. Zwykle jest to sytuacja, w której aplikacja skompilowana na
platformie 32\-bitowej bez \fI\-D_FILE_OFFSET_BITS=64\fP próbuje otworzyć plik o
rozmiarze ponad \fI(1<<31)\-1\fP bajtów; zob. też \fBO_LARGEFILE\fP
powyżej. Jest to kod błędu wynikający z POSIX.1; przed Linuksem 2.6.24,
Linux w takiej sytuacji generował błąd \fBEFBIG\fP.
.TP 
\fBEPERM\fP
.\" Strictly speaking, it's the filesystem UID... (MTK)
Podano znacznik \fBO_NOATIME\fP, ale efektywny identyfikator użytkownika
wywołującego nie równał się właścicielowi pliku, a wywołujący nie był
uprzywilejowany.
.TP 
\fBEPERM\fP
Operacja zablokowana, z powodu zapieczętowania pliku (ang. file seal);
zob. \fBfcntl\fP(2).
.TP 
\fBEROFS\fP
\fIpathname\fP odnosi się do pliku na systemie plików tylko do odczytu, a
żądano otwarcia w trybie do zapisu.
.TP 
\fBETXTBSY\fP
\fIpathname\fP odnosi się do wykonywalnego obrazu, który obecnie jest
wykonywany, a zażądano dostępu do zapisu.
.TP 
\fBETXTBSY\fP
\fIpathname\fP odnosi się do pliku, używanego obecnie jako pliku wymiany, a
podano znacznik \fBO_TRUNC\fP.
.TP 
\fBETXTBSY\fP
\fIpathname\fP odnosi się do pliku aktualnie odczytywanego przez jądro (np. do
załadowania modułu/oprogramowania układowego), a zażądano dostępu do zapisu.
.TP 
\fBEWOULDBLOCK\fP
Podano znacznik \fBO_NONBLOCK\fP, a na pliku utrzymywana jest niezgodna
dzierżawa (zob. \fBfcntl\fP(2)).
.SH WERSJE
.\" Linux 2.0, 2.5: truncate
.\" Solaris 5.7, 5.8: truncate
.\" Irix 6.5: truncate
.\" Tru64 5.1B: truncate
.\" HP-UX 11.22: truncate
.\" FreeBSD 4.7: truncate
(Niezdefiniowany) wynik \fBO_RDONLY | O_TRUNC\fP różni się w zależności od
implementacji. W wielu systemach plik jest faktycznie przycinany.
.SS "Synchronizowane wejście/wyjście"
Opcja POSIX.1\-2008 \[Bq]synchronized I/O\[rq] określa różne warianty
synchronizowanego wejścia/wyjścia i podaje znaczniki \fBO_SYNC\fP, \fBO_DSYNC\fP i
\fBO_RSYNC\fP \fBopen\fP() jako przeznaczone do kontrolowania oczekiwanego
zachowania. Niezależnie od tego, czy dana implementacja obsługuje tę opcję,
obowiązkowa jest obsługa co najmniej \fBO_SYNC\fP w przypadku zwykłych plików.
.P
Linux implementuje \fBO_SYNC\fP i \fBO_DSYNC\fP, lecz nie \fBO_RSYNC\fP. Poniekąd
niewłaściwie, glibc definiuje \fBO_RSYNC\fP jako mające tę samą wartość co
\fBO_SYNC\fP (\fBO_RSYNC\fP jest zdefiniowane w linuksowym pliku nagłówkowym
\fI<asm/fcntl.h>\fP na architekturze HP PA\-RISC, lecz nie jest
używane).
.P
\fBO_SYNC\fP zapewnia kompletność zsynchronizowanego wejścia/wyjścia \fIpliku\fP w
sposób gwarantujący spójność tzn. operacje zapisu przenoszą dane i wszystkie
powiązane metadane na przedmiotowe urządzenie. \fBO_DSYNC\fP zapewnia
kompletność zsynchronizowanego wejścia/wyjścia \fIdanych\fP w sposób
gwarantujący spójność tzn. operacje zapisu przenoszą dane na przedmiotowe
urządzenie, lecz przeniosą jedynie te aktualizowane metadane, które są
konieczne do pomyślnego zakończenia kolejnych operacji odczytu. Ta druga
metoda pozwala zredukować liczbę operacji dysku wymaganych w przypadku
aplikacji, które nie wymagają gwarancji spójności pliku.
.P
Aby zrozumieć różnicę pomiędzy tymi dwoma typami kompletności, proszę
rozważyć dwie cząstki metadanych pliku: znacznik czasu ostatniej modyfikacji
pliku (\fIst_mtime\fP) oraz długość pliku. Wszystkie operacje zapisu
zaktualizują znacznik czasu ostatniej modyfikacji pliku, lecz jedynie zapisy
dodające dane na końcu pliku, spowodują zmianę jego długości. Znacznik czasu
ostatniej modyfikacji nie jest wymagany do pomyślnego zakończenia operacji
odczytu, w przeciwieństwie do długości pliku. Zatem \fBO_DSYNC\fP zagwarantuje
jedynie zaktualizowanie metadanej długości pliku (podczas gdy \fBO_SYNC\fP
również metadanej znacznika czasu ostatniej modyfikacji pliku).
.P
Przed Linuksem 2.6.33, Linux implementował dla \fBopen\fP() jedynie znacznik
\fBO_SYNC\fP. Jednak gdy podało się ten znacznik, większość systemów plików w
rzeczywistości zapewniało równoważnik kompletności zsynchronizowanego
wejścia/wyjścia \fIdanych\fP w sposób zapewniający spójność (tj. \fBO_SYNC\fP był
zaimplementowany w rzeczywistości jako ekwiwalent \fBO_DSYNC\fP).
.P
.\"
Od Linuksa 2.6.33, zapewniona jest prawidłowa obsługa \fBO_SYNC\fP. Jednak aby
zapewnić wsteczną kompatybilność binarną, \fBO_DSYNC\fP zdefiniowano z tą samą
wartością co historyczne \fBO_SYNC\fP, a \fBO_SYNC\fP zdefiniowano jako nową
(dwubitową) wartość znacznika, która zawiera wartość znacznika \fBO_DSYNC\fP. W
ten sposób aplikacje skompilowane z nowymi nagłówkami, otrzymają co najmniej
zachowanie \fBO_DSYNC\fP przed Linuksem 2.6.33.
.SS "Różnice biblioteki C/jądra"
.\"
Od glibc 2.26, funkcja opakowująca \fBopen\fP() z glibc korzysta z wywołania
systemowego \fBopenat\fP(), zamiast z wywołania systemowego jądra \fBopen\fP(). Na
niektórych architekturach działo się to także przed glibc 2.26.
.SH STANDARDY
.TP 
\fBopen\fP()
.TQ
\fBcreat\fP()
.TQ
\fBopenat\fP()
POSIX.1\-2008.
.P
\fBopenat2\fP(2)  Linux.
.P
Znaczniki \fBO_DIRECT\fP, \fBO_NOATIME\fP, \fBO_PATH\fP i \fBO_TMPFILE\fP są typowo
linuksowe. Aby uzyskać ich definicje, należy zdefiniować \fB_GNU_SOURCE\fP.
.P
Znaczniki \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP i \fBO_NOFOLLOW\fP nie są określone w
POSIX.1\-2001, lecz są określone w POSIX.1\-2008. Od glibc 2.12, można uzyskać
ich definicje definiując albo \fB_POSIX_C_SOURCE\fP z wartością większą lub
równą 200809L, albo \fB_XOPEN_SOURCE\fP z wartością większą lub równą 700. W
glibc 2.11 i wcześniejszych, można uzyskać te definicje definiując
\fB_GNU_SOURCE\fP.
.SH HISTORIA
.TP 
\fBopen\fP()
.TQ
\fBcreat\fP()
SVr4, 4.3BSD, POSIX.1\-2001.
.TP 
\fBopenat\fP()
POSIX.1\-2008.  Linux 2.6.16, glibc 2.4.
.SH UWAGI
W Linuksie, znacznik \fBO_NONBLOCK\fP jest niekiedy używany w przypadkach, gdy
chce się otworzyć plik, ale niekonieczne ma się zamiar odczytu lub zapisu z
niego. Przykładowo można go użyć do otworzenia urządzenia, w celu uzyskania
deskryptora pliku do wykorzystania z \fBioctl\fP(2).
.P
Należy zauważyć, że \fBopen\fP() może otwierać specjalne pliki urządzeń, lecz
\fBcreat\fP() nie może ich tworzyć. Zamiast niego należy używać \fBmknod\fP(2).
.P
Jeśli plik jest nowoutworzony, to jego pola \fIst_atime\fP, \fIst_ctime\fP,
\fIst_mtime\fP (odpowiednio: czas ostatniego dostępu, czas ostatniej zmiany
statusu i czas ostatniej modyfikacji, zob. \fBstat\fP(2)) są ustawione na czas
bieżący i to samo dotyczy pól \fIst_ctime\fP i \fIst_mtime\fP katalogu
nadrzędnego. Natomiast gdy plik jest modyfikowany z powodu użycia znacznika
\fBO_TRUNC\fP, jego pola \fIst_ctime\fP i \fIst_mtime\fP są ustawiane na czas
bieżący.
.P
Pliki w katalogu \fI/proc/\fPpid\fI/fd\fP pokazują otwarte deskryptory pliku
procesu o PID równym \fIpid\fP. Pliki w katalogu \fI/proc/\fPpid\fI/fdinfo\fP
pokazują jeszcze więcej informacji o tych deskryptorach pliku. Więcej
informacji o obu tych katalogach znajduje się w podręczniku \fBproc\fP(5).
.P
.\"
.\"
Linuksowy plik nagłówkowy \fB<asm/fcntl.h>\fP nie definiuje \fBO_ASYNC\fP;
definiowany jest jednak (wywodzący się z BSD) synonim \fBFASYNC\fP.
.SS "Opisy otwartego pliku"
Termin \[Bq]opis otwartego pliku \[rq] (ang. \[Bq]open file
description\[rq]) jest używany przez POSIX w odniesieniu do wpisów w
systemowej tablicy otwartych plików. W innych kontekstach, obiekt ten miewa
również następujące określenia (w nawiasach określenia angielskie):
\[Bq]obiekt otwartego pliku\[rq] (\[Bq]open file object\[rq]), \[Bq]uchwyt
pliku\[rq] (\[Bq]file handle\[rq]), \[Bq]wpis tablicy otwartych plików\[rq]
(\[Bq]open file table entry\[rq]) albo \[em] w żargonie deweloperów jądra
\[em] \fIplik struct\fP (\[Bq]struct file\[rq]).
.P
Gdy deskryptor pliku jest duplikowany (za pomocą \fBdup\fP(2) lub podobnego),
to duplikat odnosi się do tego samego opisu otwartego pliku, co pierwotny
deskryptor pliku; oba deskryptory dzielą zatem przesunięcie pliku i
znaczniki statusu pliku. Takie dzielenie może również nastąpić między
procesami: proces potomny utworzony za pomocą \fBfork\fP(2) dziedziczy
duplikaty deskryptorów pliku swojego rodzica, a te duplikaty odnoszą się do
tych samych opisów otwartego pliku.
.P
Każde otwarcie pliku za pomocą \fBopen\fP() tworzy nowy opis otwartego pliku;
zatem może istnieć wiele opisów otwartego pliku odnoszących do i\-węzła
pliku.
.P
.\"
W Linuksie, można użyć operacji \fBKCMP_FILE\fP \fBkcmp\fP(2) do sprawdzenia, czy
dwa deskryptory pliku (w tym samym procesie lub w dwóch różnych procesach)
odnoszą się do tego samego opisu otwartego pliku.
.SS NFS
Jest wiele niedogodności w protokole podległym NFS, dotykających między
innymi \fBO_SYNC\fP i \fBO_NDELAY\fP.
.P
.\"
.\"
Na systemach NFS z włączonym mapowaniem UID\-ów, \fBopen\fP() może zwrócić
deskryptor pliku, dla którego np. żądania \fBread\fP(2) są zabronione przy
ustawionym \fBEACCES\fP. Jest to związane ze sprawdzaniem uprawnień odbywającym
się na kliencie, ale to serwer wykonuje mapowanie UID\-ów podczas żądań
odczytu i zapisu.
.SS FIFO
.\"
.\"
Otwarcie końca do odczytu lub końca do zapisu FIFO blokuje, do momentu
otwarcia również drugiego z końców (przez inny proces lub wątek). Więcej
informacji w podręczniku \fBfifo\fP(7).
.SS "Tryb dostępu do pliku"
W przeciwieństwie do innych wartości, jakie można podać we \fIflags\fP,
wartości \fItrybu dostępu\fP: \fBO_RDONLY\fP, \fBO_WRONLY\fPi \fBO_RDWR\fP nie określają
pojedynczych bitów. Definiują one dwa bity niższego rzędu \fIflags\fP i są
zdefiniowane jako, odpowiednio, 0, 1 i 2. Innymi słowy, połączenie
\fBO_RDONLY | O_WRONLY\fP jest błędem logicznym, w szczególności nie ma takiego
samego znaczenia jak \fBO_RDWR\fP.
.P
.\" See for example util-linux's disk-utils/setfdprm.c
.\" For some background on access mode 3, see
.\" http://thread.gmane.org/gmane.linux.kernel/653123
.\" "[RFC] correct flags to f_mode conversion in __dentry_open"
.\" LKML, 12 Mar 2008
.\"
.\"
Linux rezerwuje specjalny, niestandardowy tryb dostępu 3 (binarne 11) we
\fIflags\fP, do następującego znaczenia: sprawdź uprawnienia odczytu i zapisu
pliku i zwróć deskryptor pliku, który nie może być użyty do odczytu i do
zapisu. Ten niestandardowy tryb dostępu jest wykorzystywany przez niektóre
linuksowe sterowniki w celu zwrócenia deskryptora pliku, przeznaczonego
tylko do typowo \[Bq]sterownikowych\[rq] działań \fBioctl\fP(2).
.SS "Celowość API openat() i innych API katalogowych deskryptorów pliku"
\fBopenat\fP() oraz inne wywołania systemowe i funkcje biblioteczne, które
przyjmują jako argument deskryptor pliku odnoszący się do katalogu
(tj. \fBexecveat\fP(2), \fBfaccessat\fP(2), \fBfanotify_mark\fP(2), \fBfchmodat\fP(2),
\fBfchownat\fP(2), \fBfspick\fP(2), \fBfstatat\fP(2), \fBfutimesat\fP(2), \fBlinkat\fP(2),
\fBmkdirat\fP(2), \fBmknodat\fP(2), \fBmount_setattr\fP(2), \fBmove_mount\fP(2),
\fBname_to_handle_at\fP(2), \fBopen_tree\fP(2), \fBopenat2\fP(2), \fBreadlinkat\fP(2),
\fBrenameat\fP(2), \fBrenameat2\fP(2), \fBstatx\fP(2), \fBsymlinkat\fP(2),
\fBunlinkat\fP(2), \fButimensat\fP(2), \fBmkfifoat\fP(3) i \fBscandirat\fP(3))
rozwiązują dwa problemy starszych interfejsów, które je poprzedzały. Tu
podano wyjaśnienie odnoszące się do wywołania \fBopenat\fP(), jednak
analogicznie można je zastosować do pozostałych interfejsów.
.P
Przede wszystkim \fBopenat\fP() pozwala uniknąć aplikacjom wystąpienia sytuacji
wyścigu, która może zachodzić przy otwieraniu za pomocą \fBopen\fP() plików w
katalogach innych, niż bieżący katalog roboczy. Wyścig wynika z tego, że
pewna składowa ścieżki podanej \fBopen\fP() mogła ulec zmianie równolegle z
wywołaniem \fBopen\fP(). Proszę założyć na przykład, że próbujemy utworzyć plik
\fIkat1/kat2/xxx.zal\fP, jeśli plik \fIkat1/kat2/xxx\fP istnieje. Jednak pomiędzy
sprawdzeniem istnienia i krokiem utworzenia pliku, \fIkat1\fP lub \fIkat2\fP
(które mogą być dowiązaniami symbolicznymi) mogą być zdefiniowane, aby
wskazywać na inne położenia. Wyścigu można uniknąć, otwierając deskryptor
pliku katalogu docelowego, a następnie podając ten deskryptor pliku jako
argument \fIdirfd\fP do (przykładowo) \fBfstatat\fP(2) i \fBopenat\fP(). Użycie
deskryptora pliku \fIdirfd\fP ma także inne zalety:
.IP \[bu] 3
deskryptor pliku jest stabilną referencją do katalogu, nawet gdy jego nazwa
się zmieni oraz
.IP \[bu]
otwarty deskryptor pliku zapobiega odmontowaniu systemu plików, na którym
się znajduje, podobnie jak ma to miejsce w przypadku procesu, mającego swój
bieżący katalog roboczy w danym systemie plików.
.P
Po drugie, \fBopenat\fP() pozwala na implementację \[Bq]bieżącego katalogu
roboczego\[rq] przypisanego wątkowi, za pomocą deskryptora(\-ów) pliku(\-ów)
zarządzanych przez aplikację (tę funkcjonalność można też uzyskać za pomocą
sztuczek opartych na korzystaniu z \fI/proc/self/fd/\fPdirfd, lecz jest to
mniej wydajne).
.P
Argument \fIdirfd\fP do tych API można pozyskać za pomocą \fBopen\fP() lub
\fBopenat\fP() do otworzenia katalogu (ze znacznikiem \fBO_RDONLY\fP albo
\fBO_PATH\fP). Alternatywnie, taki deskryptor pliku można uzyskać stosując
\fBdirfd\fP(3) do strumienia katalogu utworzonego za pomocą \fBopendir\fP(3).
.P
.\"
.\"
W omawianych API, gdy poda się argument \fIdirfd\fP równy \fBAT_FDCWD\fP albo
podana ścieżka jest bezwzględna, API obsługują swój argument ścieżki w taki
sam sposób, jak odpowiadające im tradycyjne API. Jednak w tym przypadku,
wiele z API posiada argument \fIflags\fP, pozwalający na dostęp do
funkcjonalności, która nie jest dostępna w odpowiadającym im tradycyjnym
API.
.SS O_DIRECT
Znacznik \fBO_DIRECT\fP może nakładać ograniczenia (związane z wyrównaniem) na
długości i adresie buforów definiowanych w przestrzeni użytkownika oraz
przesunięciu pliku w wejściu/wyjściu. W Linuksie, ograniczenia związane z
wyrównaniem różnią się w zależności od systemu plików i wersji jądra, mogą
też wcale nie występować. Obsługa niewyrównanych wejść/wyjść \fBO_DIRECT\fP
również jest zróżnicowana; mogą one albo zawieść z błędem \fBEINVAL\fP, albo
awaryjnie skorzystać z buforowanego wejścia/wyjścia.
.P
Od Linuksa 6.1, obsługa \fBO_DIRECT\fP i ograniczenia wyrównania związane z
danym plikiem można sprawdzić za pomocą \fBstatx\fP(2), wykorzystując znacznik
\fBSTATX_DIOALIGN\fP. Obsługa \fBSTATX_DIOALIGN\fP różni się w zależności od
systemu plików; więcej szczegółów w podręczniku \fBstatx\fP(2).
.P
Niektóre systemy plików zapewniają swoje interfejsy do odpytywania
ograniczeń wyrównania \fBO_DIRECT\fP, przykładowo jest to operacja
\fBXFS_IOC_DIOINFO\fP w \fBxfsctl\fP(3). Gdy jednak tylko jest dostępny, należy
korzystać z \fBSTATX_DIOALIGN\fP.
.P
Jeśli żadne w powyższych nie jest dostępne, to obsługa bezpośredniego
wejścia/wyjścia oraz ograniczenia związane z wyrównaniem można odgadnąć
jedynie na podstawie znanej charakterystyki systemu plików, danego pliku,
nośnika danych i wersji jądra. W Linuksie 2.4, większość systemu plików
opartych na urządzeniach blokowych wymagało, aby długości i adresy pamięci
wszystkich segmentów wejścia/wyjścia, były wielokrotnościami rozmiaru bloku
systemu plików (zwykle 4096 bajtów). W Linuksie 2.6.0, to ograniczenie
poluzowano do logicznego rozmiaru bloku (zwykle 512 bajtów). Rozmiar
logicznego bloku urządzenia blokowego można sprawdzić za pomocą operacji
\fBBLKSSZGET\fP \fBioctl\fP(2) lub z powłoki, poleceniem:
.P
.in +4n
.EX
blockdev \-\-getss
.EE
.in
.P
Wejścia/wyjścia \fBO_DIRECT\fP nigdy nie należy uruchamiać równolegle z
wywołaniem systemowym \fBfork\fP(2), jeśli bufor pamięci jest przypisaniem
prywatnym (obejmuje to wszystkie przypisania utworzone za pomocą znacznika
\fBMAP_PRIVATE\fP \fBmmap\fP(2); w tym pamięć przydzieloną do kopca oraz bufory
przydzielone statycznie). Każde takie wejście/wyjście, niezależnie od tego,
czy zostanie przesłane poprzez interfejs asynchronicznego wejścia/wyjścia,
czy od innego wątku procesu, powinno być ukończone przed wywołaniem
\fBfork\fP(2). Jeśli tak się nie stanie, może dojść do uszkodzenia danych oraz
niezdefiniowanego zachowania w procesie macierzystym i potomnym. To
ograniczenie nie ma zastosowania w przypadku, gdy bufory pamięci do
wejścia/wyjścia \fBO_DIRECT\fP utworzono za pomocą \fBshmat\fP(2) lub \fBmmap\fP(2)
ze znacznikiem \fBMAP_SHARED\fP. Nie ma zastosowania również wtedy, gdy w
stosunku do bufora pamięci udzielono wskazówki \fBMADV_DONTFORK\fP za pomocą
\fBmadvise\fP(2), co zapewnia, że nie będzie on dostępny dla potomka po
wykonaniu \fBfork\fP(2).
.P
Znacznik \fBO_DIRECT\fP wprowadzono w SGI IRIX, gdzie ograniczenia związane z
wyrównaniem były podobne do Linuksa 2.4. IRIX ma również wywołanie
\fBfcntl\fP(2) do odpytywania o poprawne wyrównania i rozmiary. We FreeBSD 4.x
wprowadzono znacznik o tej samej nazwie, ale nieposiadający ograniczeń
wyrównania.
.P
Obsługę \fBO_DIRECT\fP dodano w Linuksie 2.4.10. Starsze jądra Linux ignorują
ten znacznik. Niektóre systemy plików mogą go nie implementować; wówczas
zastosowanie znacznika spowoduje, że \fBopen\fP() zawiedzie z błędem \fBEINVAL\fP.
.P
Aplikacje powinny unikać mieszania \fBO_DIRECT\fP i zwykłego wejścia/wyjścia w
tym samym pliku, szczególnie w nachodzących na siebie obszarach pliku. Nawet
gdy system plików poprawnie obsługuje zagadnienia związane ze spójnością
danych w tej sytuacji, sumaryczna przepustowość wejścia/wyjścia będzie
prawdopodobnie gorsza, niż przy zdecydowaniu się na któryś z
trybów. Aplikacje powinny również unikać mieszania korzystania z \fBmmap\fP(2)
na plikach, przy używaniu bezpośredniego wejścia/wyjścia do tych samych
plików.
.P
Zachowanie \fBO_DIRECT\fP w systemie NFS różni się od lokalnych systemów
plików. Starsze jądra oraz jądra skonfigurowane w pewien sposób mogą nie
obsługiwać tego połączenia. Protokół NFS nie obsługuje przekazywania
znacznika serwerowi, zatem wejście/wyjście \fBO_DIRECT\fP pominie buforowanie
strony tylko po stronie klienta; serwer wciąż może buforować
wejście/wyjście. Klient prosi serwer o uczynienie wejścia/wyjścia
synchronicznym, aby zachować synchroniczne zachowanie \fBO_DIRECT\fP. Niektóre
serwery nie będą się zachowywały wydajnie w takim przypadku, szczególnie
jeśli rozmiar wejścia/wyjścia jest niewielki. Niektóre serwery mogą być
również skonfigurowane w ten sposób, aby informować klientów nieprawidłowo
(przedwcześnie) o osiągnięciu stabilnego nośnika przez wejście/wyjście; ta
metoda unika uszczerbku wydajności kosztem pewnego ryzyka utraty spójności
danych w przypadku awarii zasilania serwera. Linuksowy klient NFS nie
narzuca ograniczeń związanych z wyrównaniem w przypadku wejścia/wyjścia
\fBO_DIRECT\fP.
.P
Podsumowując, \fBO_DIRECT\fP jest narzędziem o potencjalnie dużych
możliwościach, którego należy używać ze sporą dawką ostrożności. Zaleca się,
aby aplikacje korzystające z \fBO_DIRECT\fP, traktowały go jako, domyślnie
wyłączoną, opcję poprawiającą wydajność.
.SH USTERKI
.\" FIXME . Check bugzilla report on open(O_ASYNC)
.\" See http://bugzilla.kernel.org/show_bug.cgi?id=5993
Obecnie nie da się włączyć wejścia/wyjścia sterowanego sygnałem podając
znacznik \fBO_ASYNC\fP przy wywołaniu \fBopen\fP(); należy użyć \fBfcntl\fP(2), aby
włączyć ten znacznik.
.P
Przy próbie określenia, czy jądro obsługuje funkcję \fBO_TMPFILE\fP, należy
sprawdzać dwa różne kody błędu: \fBEISDIR\fP i \fBENOENT\fP.
.P
Jeśli we \fIflags\fP poda się \fBO_CREAT\fP oraz \fBO_DIRECTORY\fP, a plik podany w
ścieżce \fIpathname\fP nie istnieje, \fBopen\fP() utworzy zwykły plik
(tj. \fBO_DIRECTORY\fP zostanie zignorowany).
.SH "ZOBACZ TAKŻE"
\fBchmod\fP(2), \fBchown\fP(2), \fBclose\fP(2), \fBdup\fP(2), \fBfcntl\fP(2), \fBlink\fP(2),
\fBlseek\fP(2), \fBmknod\fP(2), \fBmmap\fP(2), \fBmount\fP(2), \fBopen_by_handle_at\fP(2),
\fBopenat2\fP(2), \fBread\fP(2), \fBsocket\fP(2), \fBstat\fP(2), \fBumask\fP(2),
\fBunlink\fP(2), \fBwrite\fP(2), \fBfopen\fP(3), \fBacl\fP(5), \fBfifo\fP(7), \fBinode\fP(7),
\fBpath_resolution\fP(7), \fBsymlink\fP(7)
.PP
.SH TŁUMACZENIE
Tłumaczenie niniejszej strony podręcznika:
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 .
