.\" -*- 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 .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified 1993-07-21 by Rik Faith .\" Modified 1994-08-21 by Michael Haardt .\" Modified 1996-04-13 by Andries Brouwer .\" Modified 1996-05-13 by Thomas Koenig .\" Modified 1996-12-20 by Michael Haardt .\" Modified 1999-02-19 by Andries Brouwer .\" Modified 1998-11-28 by Joseph S. Myers .\" Modified 1999-06-03 by Michael Haardt .\" Modified 2002-05-07 by Michael Kerrisk .\" Modified 2004-06-23 by Michael Kerrisk .\" 2004-12-08, mtk, reordered flags list alphabetically .\" 2004-12-08, Martin Pool (& 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 .\" and Timo Sirainen .\" Rewrite description of O_EXCL. .\" 2008-01-11, Greg Banks : 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 \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\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\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 , 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 .