Provided by: manpages-pl-dev_4.23.1-1_all 
NAZWA
open, creat - otwiera i ewentualnie tworzy plik
BIBLIOTEKA
Standardowa biblioteka C (libc, -lc)
SKŁADNIA
#include <fcntl.h>
int open(const char *pathname, int flags, ...
/* mode_t mode */ );
int creat(const char *pathname, mode_t mode);
int openat(int dirfd, const char *pathname, int flags, ...
/* mode_t mode */ );
/* Udokumentowane oddzielnie, w openat2(2):
*/
int openat2(int dirfd, const char *pathname,
const struct open_how *how, size_t size);
Wymagane ustawienia makr biblioteki glibc (patrz feature_test_macros(7)):
openat():
Od glibc 2.10:
_POSIX_C_SOURCE >= 200809L
Przed glibc 2.10:
_ATFILE_SOURCE
OPIS
Wywołanie systemowe open() otwiera plik określony ścieżką pathname. Jeśli podany plik nie
istnieje, może być opcjonalnie (jeśli we flags podano O_CREAT) utworzony przez open().
Wartością zwracaną przez open() 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 (read(2), write(2),
lseek(2), fcntl(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.
Domyślnie, nowy deskryptor pliku jest ustawiany jako pozostający otwarty po wykonaniu
przez execve(2) (tj. znacznik deskryptora pliku FD_CLOEXEC opisany w fcntl(2) jest
początkowo wyłączony); można użyć opisanego poniżej znacznika O_CLOEXEC aby zmienić to
zachowanie. Przesunięcie pliku jest ustawiane na początek pliku (zob. lseek(2)).
Wywołanie open() tworzy nowy opis otwartego pliku, 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 pathname lub jej modyfikacja, w celu wskazania innego
pliku. Więcej informacji o opisach otwartego pliku zawarto w rozdziale UWAGI.
Argument flags musi zawierać jeden z następujących trybów dostępu: O_RDONLY, O_WRONLY lub
O_RDWR. Stanowią one, odpowiednio, żądania otwarcia tylko do odczytu, tylko do zapisu, lub
do odczytu i zapisu.
Ponadto, we flags może zsumować bitowo (OR) zero lub więcej znaczników tworzenia pliku i
znaczników statusu pliku. Znaczniki tworzenia pliku to: O_CLOEXEC, O_CREAT, O_DIRECTORY,
O_EXCL, O_NOCTTY, O_NOFOLLOW, O_TMPFILE i O_TRUNC. Znaczniki statusu pliku 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 fcntl(2).
Oto pełna lista znaczników tworzenia pliku i znaczników statusu pliku:
O_APPEND
Plik jest otwierany w trybie dopisywania. Przed każdą operacją write(2),
przesunięcie pliku jest ustawiane na koniec pliku, jak z lseek(2). Modyfikacja
przesunięcia pliku i operacja zapisu jest przeprowadzana jako jeden, niepodzielny
krok.
O_APPEND 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.
O_ASYNC
Włącza wejście/wyjście sterowane sygnałem: generuje sygnał (domyślnie SIGIO, ale
można go zmienić za pomocą fcntl(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 fcntl(2). Zob. też USTERKI poniżej.
O_CLOEXEC (od Linuksa 2.6.23)
Włącza znacznik zamknięcia-przy-wykonaniu dla nowego deskryptora pliku. Podanie
tego znacznika umożliwia uniknięcie przez program wykonywania dodatkowych operacji
F_SETFD fcntl(2) w celu ustawienia znacznika FD_CLOEXEC.
Proszę zauważyć, że korzystanie z tego znacznika jest niezbędne w niektórych
programach wielowątkowych, ponieważ oddzielna operacja F_SETFD fcntl(2),
ustawiająca znacznik FD_CLOEXEC, 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ą fcntl(2), a w tym samym czasie inny wątek
dokonuje fork(2) oraz execve(2). W zależności od kolejności wykonania, wyścig ten
może spowodować nieoczekiwany wyciek deskryptora pliku zwróconego przez open(), do
programu wykonywanego przez proces potomny utworzony przez fork(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 O_CLOEXEC, aby poradzić sobie z tym problemem).
O_CREAT
Jeśli pathname nie istnieje, tworzy ją jako zwykły plik.
Właściciel (identyfikator użytkownika) nowego pliku jest ustawiany na efektywny
identyfikator użytkownika procesu.
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 bsdgroups i sysvgroups, które opisano w podręczniku
mount(8).
Argument mode określa bity trybu pliku, jakie mają być zastosowane do nowo
tworzonego pliku. Jeśli nie poda się O_CREAT ani O_TMPFILE we flags, to mode jest
ignorowane (można je zatem podać jako 0 lub po prostu pominąć). Argument mode musi
być określony, jeśli we flags podano O_CREAT lub O_TMPFILE; jeśli się go nie poda,
jako tryb pliku zostaną użyte jakieś losowe bajty ze stosu.
Efektywny tryb jest modyfikowany przez umask procesu, w zwykły sposób: pod
nieobecność domyślnych list kontroli dostępu (ACL), trybem tworzonego pliku jest
(mode & ~umask).
Proszę zauważyć, że mode stosuje się tylko do kolejnych dostępów do nowo tworzonego
pliku; wywołanie open(), które tworzy plik tylko do odczytu, może zwrócić również
deskryptor pliku do odczytu i do zapisu.
Dla parametru mode udostępniono następujące stałe symboliczne:
S_IRWXU 00700 użytkownik (właściciel pliku) ma prawa odczytu, zapisu i
uruchamiania.
S_IRUSR 00400 użytkownik ma prawa odczytu.
S_IWUSR 00200 użytkownik ma prawa zapisu.
S_IXUSR 00100 użytkownik ma prawa uruchamiania.
S_IRWXG 00070 grupa ma prawa odczytu, zapisu i uruchamiania.
S_IRGRP 00040 grupa ma prawa odczytu.
S_IWGRP 00020 grupa ma prawa zapisu.
S_IXGRP 00010 grupa ma prawa uruchamiania.
S_IRWXO 00007 inni mają prawa odczytu, zapisu i uruchamiania.
S_IROTH 00004 inni mają prawa odczytu.
S_IWOTH 00002 inni mają prawa zapisu.
S_IXOTH 00001 inni mają prawa uruchamiania.
Zgodnie z POSIX, wpływ ustawienia innych bitów w mode jest nieokreślony. W
Linuksie, honorowane jest również ustawienie następujących bitów w mode:
S_ISUID 0004000 bit set-user-ID
S_ISGID 0002000 bit set-group-ID (zob. inode(7)).
S_ISVTX 0001000 bit lepkości (zob. inode(7)).
O_DIRECT (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 O_DIRECT stara się dokonywać transferu
synchronicznie, ale nie daje gwarancji znacznika O_SYNC, że dane i wymagane
metadane są transferowane. Aby zagwarantować synchroniczne wejście/wyjście, oprócz
O_DIRECT konieczne jest użycie również O_SYNC. Więcej informacji w rozdziale UWAGI
poniżej.
Semantycznie podobny (lecz przestarzały) interfejs dla urządzeń blokowych opisano w
raw(8).
O_DIRECTORY
Jeśli pathname nie jest katalogiem, spowoduje niepowodzenie otwarcia. Ten znacznik
dodano w Linuksie 2.1.126, aby uniknąć problemów blokowania usług (DoS), gdy
opendir(3) jest wywołane dla FIFO lub dla urządzenia taśmowego.
O_DSYNC
Operacje zapisu pliku zakończą się zgodnie z wymaganiem kompletności
zsynchronizowanego wejścia/wyjścia danych w sposób gwarantujący spójność.
W chwili powrotu write(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 write(2)
wywoływać fdatasync(2)). Proszę zapoznać się z UWAGAMI poniżej.
O_EXCL Zapewnia, że to wywołanie utworzy plik: jeśli znacznik poda się razem z O_CREAT, a
ścieżka pathname już istnieje, to open() zawiedzie z błędem EEXIST.
Po podaniu obu tych znaczników, nie podąża się za dowiązaniami symbolicznymi: jeśli
pathname jest dowiązaniem symbolicznym, to open() zawiedzie niezależnie od tego, na
co wskazuje to dowiązanie symboliczne.
Co do zasady, zachowanie O_EXCL jest niezdefiniowane, jeśli użyje się go bez
O_CREAT. Jest jeden wyjątek: w Linuksie 2.6 i późniejszych, O_EXCL można użyć bez
O_CREAT jeśli pathname odnosi się do urządzenia blokowego. Jeśli urządzenie blokowe
jest w użyciu przez system (np. jest zamontowane), to open() zawiedzie z błędem
EBUSY.
W systemie plików NFS O_EXCL 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
O_EXCL, 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
O_EXCL w NFS, mogą tworzyć unikalny plik na tym samym systemie plików (np.
wykorzystując nazwę stacji i PID) i używać link(2) do utworzenia dowiązania do
pliku-blokady. Jeśli link(2) zwróci 0, to utworzenie blokady się powiodło. W
przeciwnym razie, należy użyć stat(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.
O_LARGEFILE
(LFS) Pozwala na otwarcie plików, których rozmiarów nie można przedstawić w off_t
(lecz można w off64_t). Konieczne jest zdefiniowanie makra _LARGEFILE64_SOURCE
(przed włączeniem jakichkolwiek plików nagłówkowych) aby uzyskać jego definicję.
Ustawienie makra sprawdzania cech _FILE_OFFSET_BITS na 64 (zamiast na O_LARGEFILE)
jest preferowaną metodą uzyskiwania dostępu do dużych plików w systemach
32-bitowych (zob. feature_test_macros(7)).
O_NOATIME (od Linuksa 2.6.8)
Nie aktualizuje czasu ostatniego dostępu do pliku (st_atime w i-węźle) gdy plik
jest odczytywany (read(2)).
Znacznik ten można użyć tylko, jeśli spełniony zostanie jeden z poniższych
warunków:
• Efektywny UID procesu jest zgodny z UID-em właściciela pliku.
• Proces wywołujący ma przywilej CAP_FOWNER (ang. capability) w swojej przestrzeni
nazw użytkownika, a UID właściciela pliku ma przypisanie do tej przestrzeni
nazw.
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.
O_NOCTTY
Jeśli pathname odnosi się do urządzenia terminalowego — zob. tty(4) — to nie stanie
się terminalem sterującym procesu, nawet jeśli proces takiego nie ma.
O_NOFOLLOW
Jeśli końcowa składowa (basename) ścieżki pathname jest dowiązaniem symbolicznym,
to otwarcie zawiedzie z błędem ELOOP. Dowiązania symboliczne wcześniejszych
składowych ścieżki wciąż zostaną rozwinięte (proszę zauważyć, że błąd ELOOP, 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).
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.
Zob. też O_PATH poniżej.
O_NONBLOCK lub O_NDELAY
Plik jest otwierany w trybie nieblokującym, o ile to możliwe. Ani open() ani
kolejne operacje wejścia/wyjścia, na zwróconym przez to wywołanie deskryptorze, nie
spowodują blokowania procesu wywołującego.
Proszę zauważyć, że ustawienie tego znacznika nie ma wpływu na działanie poll(2),
select(2), epoll(7) i podobnych, ponieważ interfejsy te jedynie informują
wywołującego o tym, gdy deskryptor pliku jest „gotowy” co oznacza, że operacja
wejścia/wyjścia na deskryptorze pliku ze znacznikiem O_NONBLOCK zdecydowanie nie
prowadziłaby do zablokowania.
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 O_NONBLOCK. Ponieważ takie
zachowanie O_NONBLOCK 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.
Szczegóły dotyczące obsługi FIFO (nazwanych potoków) można znaleźć w podręczniku
fifo(7). Opis wpływu znacznika O_NONBLOCK, w połączeniu z blokadami obowiązującymi
(przymusowymi) oraz z dzierżawami pliku, znajduje się w podręczniku fcntl(2).
O_PATH (od Linuksa 2.6.39)
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. read(2), write(2), fchmod(2), fchown(2), fgetxattr(2),
ioctl(2), mmap(2)) zawiodą z błędem EBADF.
Na wynikowym deskryptorze pliku można wykonać następujące operacje:
• close(2).
• fchdir(2), jeśli deskryptor pliku odnosi się do katalogu (od Linuksa 3.5).
• fstat(2) (od Linuksa 3.6).
• fstatfs(2) (od Linuksa 3.12).
• Zduplikowanie deskryptora pliku (dup(2), F_DUPFD z fcntl(2), itp).
• Uzyskanie i ustawienie znaczników deskryptora pliku (F_GETFD i F_SETFD z
fcntl(2)).
• Pobranie znaczników statusu otwartego pliku za pomocą operacji F_GETFL z
fcntl(2): zwrócone znaczniki będą obejmowały również bit O_PATH.
• Przekazanie deskryptora pliku jako argumentu dirfd do openat() i innych wywołań
systemowych „*at()”. Obejmuje to również linkat(2) z AT_EMPTY_PATH (lub za
pomocą procfs wykorzystując AT_SYMLINK_FOLLOW) nawet, gdy plik nie jest
katalogiem.
• Przekazanie deskryptora pliku do innego procesu za pomocą gniazda domeny Uniksa
(zob. SCM_RIGHTS w podręczniku unix(7)).
Gdy O_PATH poda się we flags, to bity znaczników inne niż O_CLOEXEC, O_DIRECTORY i
O_NOFOLLOW są ignorowane.
Otwarcie pliku lub katalogu ze znacznikiem O_PATH 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. fchdir(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 O_RDONLY, wymagane jest posiadanie przez wywołującego
uprawnienia odczytu, nawet gdy kolejna operacja (np. fchdir(2), fstat(2)) nie
wymaga uprawnienia odczytu do obiektu.
Jeśli pathname jest dowiązaniem symbolicznym i podano również znacznik O_NOFOLLOW,
to wywołanie zwróci deskryptor pliku odnoszący się do dowiązania symbolicznego. Ten
deskryptor pliku może służyć jako argument dirfd w wywołaniach do fchownat(2),
fstatat(2), linkat(2) i readlinkat(2) z pustą ścieżką, aby wywołania działały na
samym dowiązaniu symbolicznym.
Jeśli pathname 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ć fstatfs(2), aby
sprawdzić, czy jest to faktycznie niewyzwolony punkt automatycznego montowania
(.f_type == AUTOFS_SUPER_MAGIC).
Można użyć O_PATH w przypadku zwykłych plików, aby uzyskać funkcjonalność
równoważną O_EXEC 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:
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);
Deskryptor pliku O_PATH może być również przekazany jako argument fexecve(3).
O_SYNC Operacje zapisu na pliku zakończą się zgodnie z wymaganiem kompletności
zsynchronizowanego wejścia/wyjścia pliku w sposób gwarantujący spójność (odmiennie
od zakończenia zgodnie z wymaganiem kompletności zsynchronizowanego wejścia/wyjścia
danych, udostępnianego przez O_DSYNC).
W chwili powrotu write(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 write(2) wywoływać fsync(2)). Proszę zapoznać się z UWAGAMI poniżej.
O_TMPFILE (od Linuksa 3.11)
Tworzy nienazwany, zwykły plik tymczasowy. Argument pathname 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ę.
Ze znacznikiem O_TMPFILE należy użyć O_RDWR lub O_WRONLY i, opcjonalnie, O_EXCL.
Jeśli nie poda się O_EXCL, to można skorzystać z linkat(2) do utworzenia dowiązania
do systemu plików, czyniąc plik stałym, za pomocą kodu podobnego do poniższego:
char path[PATH_MAX];
fd = open("/ścieżka/do/katalogu", O_TMPFILE | O_RDWR,
S_IRUSR | S_IWUSR);
/* Wejście/wyjście na 'fd'... */
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);
*/
W tym przypadku argument mode open() określa tryb uprawnień pliku, podobnie jak
przy O_CREAT.
Podanie O_EXCL w połączeniu z O_TMPFILE zapobiega możliwości utworzenia dowiązania
do systemu plików w powyższy sposób (proszę zauważyć, że znaczenie O_EXCL w tym
przypadku różni się od znaczenia O_EXCL w pozostałych przypadkach).
Istnieją dwa główne zastosowania O_TMPFILE:
• Usprawniona funkcjonalność tmpfile(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.
• 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
(fchown(2), fchmod(2), fsetxattr(2) itp.) przed niepodzielnym utworzeniem
dowiązania do systemu plików, w stanie już w pełni ukształtowanym (za pomocą
opisanego wyżej linkat(2)).
O_TMPFILE 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)
O_TRUNC
Jeśli plik już istnieje, jest zwykłym plikiem i tryb dostępu pozwala na zapis (tzn.
jest to O_RDWR lub O_WRONLY), to plik ten zostanie obcięty do zerowej długości.
Jeśli plik to FIFO lub urządzenie terminalowe, to znacznik O_TRUNC jest ignorowany.
W pozostałych przypadkach efekt użycia znacznika O_TRUNC jest nieokreślony.
creat()
Wywołanie creat() jest równoważne wywołaniu open() z argumentem flags ustawionym na
O_CREAT|O_WRONLY|O_TRUNC.
openat()
Wywołanie systemowe openat() operuje w dokładnie taki sam sposób jak open(), z wyjątkiem
różnic opisanych tutaj.
Argument dirfd jest używany w połączeniu z argumentem pathname, w następujący sposób:
• Jeśli ścieżka podana w pathname jest bezwzględna, to dirfd jest ignorowane.
• Jeśli ścieżka podana w pathname jest względna, a dirfd ma wartość specjalną AT_FDCWD,
to pathname jest interpretowana względem bieżącego katalogu roboczego procesu
wywołującego (jak open()).
• Jeśli ścieżka podana w pathname jest względna, to jest interpretowana względem
katalogu, do którego odnosi się deskryptor pliku dirfd (zamiast w odniesieniu do
bieżącego katalogu roboczego procesu wywołującego, jak czyni to open() w stosunku do
ścieżek względnych). W tym przypadku, dirfd musi być katalogiem, który był otwarty do
odczytu (O_RDONLY) lub za pomocą znacznika O_PATH.
Jeśli ścieżka podana w pathname jest względna, a dirfd nie jest prawidłowym deskryptorem
pliku, to wystąpi błąd (EBADF; można zatem posłużyć się tym mechanizmem do upewnienia się,
że ścieżka pathname jest bezwzględna, podając w dirfd nieprawidłowy numer deskryptora).
openat2(2)
Wywołanie systemowe openat2(2) jest rozszerzeniem openat() i udostępnia nadzbiór funkcji
wobec openat(). Jest udokumentowane oddzielnie, w podręczniku openat2(2).
WARTOŚĆ ZWRACANA
W przypadku powodzenia, open(), openat() i creat() zwracają nowy deskryptor pliku (liczbę
nieujemną). W razie wystąpienia błędu zwracane jest -1 i ustawiane errno wskazując błąd.
BŁĘDY
open(), openat() i creat() mogą zawieść z powodu następujących błędów:
EACCES Żądany dostęp do pliku nie jest dozwolony, odmówiono uprawnienia przeszukiwania dla
jednego z katalogów składowych ścieżki pathname, plik jeszcze nie istnieje i nie
dozwolono na dostęp do zapisu do katalogu nadrzędnego (zob. też
path_resolution(7)).
EACCES Gdy podano O_CREAT, włączona jest kontrolka systemowa sysctl protected_fifos lub
protected_regular, 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 /proc/sys/fs/protected_fifos i
/proc/sys/fs/protected_regular w podręczniku proc_sys_fs(5).
EBADF (openat()) pathname jest względne, lecz dirfd nie wynosi ani AT_FDCWD, ani nie
jest prawidłowym deskryptorem pliku.
EBUSY We flags podano O_EXCL, a ścieżka pathname odnosi się do urządzenia blokowego,
które jest w użyciu przez system (np. jest zamontowane).
EDQUOT Podano O_CREAT, plik nie istnieje, a przydział bloków dyskowych lub i-węzłów dla
użytkownika w systemie plików wyczerpał się.
EEXIST pathname już istnieje, a użyto O_CREAT i O_EXCL.
EFAULT pathname wskazuje poza dostępną dla użytkownika przestrzeń adresową.
EFBIG Zob. EOVERFLOW.
EINTR 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. fifo(7))
urządzeniu; zob. signal(7).
EINVAL System plików nie obsługuje znacznika O_DIRECT. Więcej informacji w UWAGACH.
EINVAL Nieprawidłowa wartość we flags.
EINVAL We flags podano O_TMPFILE, lecz nie podano O_WRONLY, ani O_RDWR.
EINVAL We flags podano O_CREAT, lecz ostatnia składowa („basename”) ścieżki pathname
nowego pliku jest nieprawidłowa (np. zawiera znaki, które nie są dozwolone w danym
systemie plików).
EINVAL Ostatnia składowa („basename”) ścieżki pathname jest nieprawidłowa (np. zawiera
znaki, które nie są dozwolone w danym systemie plików).
EISDIR pathname odnosi się do katalogu, a żądany był dostęp z prawem zapisu (tzn.
ustawione było O_WRONLY lub O_RDWR).
EISDIR pathname odnosi się do istniejącego katalogu, we flags podano O_TMPFILE i jeden z:
O_WRONLY lub O_RDWR, lecz ta wersja jądra nie zapewnia funkcjonalności O_TMPFILE.
ELOOP Podczas rozwiązywania pathname napotkano zbyt wiele dowiązań symbolicznych.
ELOOP pathname była dowiązaniem symbolicznym, a we flags podano O_NOFOLLOW, lecz nie
podano O_PATH.
EMFILE Osiągnięto limit liczby otwartych deskryptorów pliku na proces (zob. opis
RLIMIT_NOFILE w podręczniku getrlimit(2)).
ENAMETOOLONG
pathname było zbyt długie.
ENFILE Zostało osiągnięte systemowe ograniczenie na całkowitą liczbę otwartych plików.
ENODEV pathname 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
ENXIO).
ENOENT Nie ustawiono O_CREAT, a nazwany plik nie istnieje.
ENOENT Składowa pathname, która powinna być katalogiem nie istnieje lub jest wiszącym
dowiązaniem symbolicznym.
ENOENT pathname odnosi się do nieistniejącego katalogu, we flags podano O_TMPFILE i jeden
z: O_WRONLY lub O_RDWR, lecz ta wersja jądra nie zapewnia funkcjonalności
O_TMPFILE.
ENOMEM 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. pipe(7).
ENOMEM Brak pamięci jądra.
ENOSPC Gdy pathname miało być utworzone, okazało się, że na urządzeniu na którym miało się
znajdować brak miejsca na nowy plik.
ENOTDIR
Składowa użyta w pathname jako katalog w rzeczywistości nie jest katalogiem lub
podano O_DIRECTORY, a pathname nie było katalogiem.
ENOTDIR
(openat()) pathname jest ścieżką względną a dirfd jest deskryptorem pliku
odnoszącym się do pliku zamiast do katalogu.
ENXIO Podano O_NONBLOCK | O_WRONLY, plik o zadanej nazwie stanowi FIFO i nie jest ono
otwarte dla żadnego procesu do odczytu.
ENXIO Plik jest specjalnym plikiem urządzenia, a odpowiadające mu urządzenie nie
istnieje.
ENXIO Plik jest gniazdem domeny Uniksa.
EOPNOTSUPP
System plików zawierający pathname nie obsługuje O_TMPFILE.
EOVERFLOW
Ścieżka pathname 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 -D_FILE_OFFSET_BITS=64 próbuje otworzyć plik o rozmiarze ponad
(1<<31)-1 bajtów; zob. też O_LARGEFILE powyżej. Jest to kod błędu wynikający z
POSIX.1; przed Linuksem 2.6.24, Linux w takiej sytuacji generował błąd EFBIG.
EPERM Podano znacznik O_NOATIME, ale efektywny identyfikator użytkownika wywołującego nie
równał się właścicielowi pliku, a wywołujący nie był uprzywilejowany.
EPERM Operacja zablokowana, z powodu zapieczętowania pliku (ang. file seal); zob.
fcntl(2).
EROFS pathname odnosi się do pliku na systemie plików tylko do odczytu, a żądano otwarcia
w trybie do zapisu.
ETXTBSY
pathname odnosi się do wykonywalnego obrazu, który obecnie jest wykonywany, a
zażądano dostępu do zapisu.
ETXTBSY
pathname odnosi się do pliku, używanego obecnie jako pliku wymiany, a podano
znacznik O_TRUNC.
ETXTBSY
pathname 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.
EWOULDBLOCK
Podano znacznik O_NONBLOCK, a na pliku utrzymywana jest niezgodna dzierżawa (zob.
fcntl(2)).
WERSJE
(Niezdefiniowany) wynik O_RDONLY | O_TRUNC różni się w zależności od implementacji. W
wielu systemach plik jest faktycznie przycinany.
Synchronizowane wejście/wyjście
Opcja POSIX.1-2008 „synchronized I/O” określa różne warianty synchronizowanego
wejścia/wyjścia i podaje znaczniki O_SYNC, O_DSYNC i O_RSYNC open() jako przeznaczone do
kontrolowania oczekiwanego zachowania. Niezależnie od tego, czy dana implementacja
obsługuje tę opcję, obowiązkowa jest obsługa co najmniej O_SYNC w przypadku zwykłych
plików.
Linux implementuje O_SYNC i O_DSYNC, lecz nie O_RSYNC. Poniekąd niewłaściwie, glibc
definiuje O_RSYNC jako mające tę samą wartość co O_SYNC (O_RSYNC jest zdefiniowane w
linuksowym pliku nagłówkowym <asm/fcntl.h> na architekturze HP PA-RISC, lecz nie jest
używane).
O_SYNC zapewnia kompletność zsynchronizowanego wejścia/wyjścia pliku w sposób gwarantujący
spójność tzn. operacje zapisu przenoszą dane i wszystkie powiązane metadane na
przedmiotowe urządzenie. O_DSYNC zapewnia kompletność zsynchronizowanego wejścia/wyjścia
danych 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.
Aby zrozumieć różnicę pomiędzy tymi dwoma typami kompletności, proszę rozważyć dwie
cząstki metadanych pliku: znacznik czasu ostatniej modyfikacji pliku (st_mtime) 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 O_DSYNC zagwarantuje jedynie
zaktualizowanie metadanej długości pliku (podczas gdy O_SYNC również metadanej znacznika
czasu ostatniej modyfikacji pliku).
Przed Linuksem 2.6.33, Linux implementował dla open() jedynie znacznik O_SYNC. 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 danych w sposób zapewniający spójność (tj.
O_SYNC był zaimplementowany w rzeczywistości jako ekwiwalent O_DSYNC).
Od Linuksa 2.6.33, zapewniona jest prawidłowa obsługa O_SYNC. Jednak aby zapewnić wsteczną
kompatybilność binarną, O_DSYNC zdefiniowano z tą samą wartością co historyczne O_SYNC, a
O_SYNC zdefiniowano jako nową (dwubitową) wartość znacznika, która zawiera wartość
znacznika O_DSYNC. W ten sposób aplikacje skompilowane z nowymi nagłówkami, otrzymają co
najmniej zachowanie O_DSYNC przed Linuksem 2.6.33.
Różnice biblioteki C/jądra
Od glibc 2.26, funkcja opakowująca open() z glibc korzysta z wywołania systemowego
openat(), zamiast z wywołania systemowego jądra open(). Na niektórych architekturach
działo się to także przed glibc 2.26.
STANDARDY
open()
creat()
openat()
POSIX.1-2008.
openat2(2) Linux.
Znaczniki O_DIRECT, O_NOATIME, O_PATH i O_TMPFILE są typowo linuksowe. Aby uzyskać ich
definicje, należy zdefiniować _GNU_SOURCE.
Znaczniki O_CLOEXEC, O_DIRECTORY i O_NOFOLLOW 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
_POSIX_C_SOURCE z wartością większą lub równą 200809L, albo _XOPEN_SOURCE z wartością
większą lub równą 700. W glibc 2.11 i wcześniejszych, można uzyskać te definicje
definiując _GNU_SOURCE.
HISTORIA
open()
creat()
SVr4, 4.3BSD, POSIX.1-2001.
openat()
POSIX.1-2008. Linux 2.6.16, glibc 2.4.
UWAGI
W Linuksie, znacznik O_NONBLOCK 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 ioctl(2).
Należy zauważyć, że open() może otwierać specjalne pliki urządzeń, lecz creat() nie może
ich tworzyć. Zamiast niego należy używać mknod(2).
Jeśli plik jest nowoutworzony, to jego pola st_atime, st_ctime, st_mtime (odpowiednio:
czas ostatniego dostępu, czas ostatniej zmiany statusu i czas ostatniej modyfikacji, zob.
stat(2)) są ustawione na czas bieżący i to samo dotyczy pól st_ctime i st_mtime katalogu
nadrzędnego. Natomiast gdy plik jest modyfikowany z powodu użycia znacznika O_TRUNC, jego
pola st_ctime i st_mtime są ustawiane na czas bieżący.
Pliki w katalogu /proc/pid/fd pokazują otwarte deskryptory pliku procesu o PID równym pid.
Pliki w katalogu /proc/pid/fdinfo pokazują jeszcze więcej informacji o tych deskryptorach
pliku. Więcej informacji o obu tych katalogach znajduje się w podręczniku proc(5).
Linuksowy plik nagłówkowy <asm/fcntl.h> nie definiuje O_ASYNC; definiowany jest jednak
(wywodzący się z BSD) synonim FASYNC.
Opisy otwartego pliku
Termin „opis otwartego pliku ” (ang. „open file description”) 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): „obiekt
otwartego pliku” („open file object”), „uchwyt pliku” („file handle”), „wpis tablicy
otwartych plików” („open file table entry”) albo — w żargonie deweloperów jądra — plik
struct („struct file”).
Gdy deskryptor pliku jest duplikowany (za pomocą dup(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ą fork(2) dziedziczy duplikaty
deskryptorów pliku swojego rodzica, a te duplikaty odnoszą się do tych samych opisów
otwartego pliku.
Każde otwarcie pliku za pomocą open() tworzy nowy opis otwartego pliku; zatem może istnieć
wiele opisów otwartego pliku odnoszących do i-węzła pliku.
W Linuksie, można użyć operacji KCMP_FILE kcmp(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.
NFS
Jest wiele niedogodności w protokole podległym NFS, dotykających między innymi O_SYNC i
O_NDELAY.
Na systemach NFS z włączonym mapowaniem UID-ów, open() może zwrócić deskryptor pliku, dla
którego np. żądania read(2) są zabronione przy ustawionym EACCES. Jest to związane ze
sprawdzaniem uprawnień odbywającym się na kliencie, ale to serwer wykonuje mapowanie
UID-ów podczas żądań odczytu i zapisu.
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 fifo(7).
Tryb dostępu do pliku
W przeciwieństwie do innych wartości, jakie można podać we flags, wartości trybu dostępu:
O_RDONLY, O_WRONLYi O_RDWR nie określają pojedynczych bitów. Definiują one dwa bity
niższego rzędu flags i są zdefiniowane jako, odpowiednio, 0, 1 i 2. Innymi słowy,
połączenie O_RDONLY | O_WRONLY jest błędem logicznym, w szczególności nie ma takiego
samego znaczenia jak O_RDWR.
Linux rezerwuje specjalny, niestandardowy tryb dostępu 3 (binarne 11) we flags, 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 „sterownikowych” działań ioctl(2).
Celowość API openat() i innych API katalogowych deskryptorów pliku
openat() oraz inne wywołania systemowe i funkcje biblioteczne, które przyjmują jako
argument deskryptor pliku odnoszący się do katalogu (tj. execveat(2), faccessat(2),
fanotify_mark(2), fchmodat(2), fchownat(2), fspick(2), fstatat(2), futimesat(2),
linkat(2), mkdirat(2), mknodat(2), mount_setattr(2), move_mount(2), name_to_handle_at(2),
open_tree(2), openat2(2), readlinkat(2), renameat(2), renameat2(2), statx(2),
symlinkat(2), unlinkat(2), utimensat(2), mkfifoat(3) i scandirat(3)) rozwiązują dwa
problemy starszych interfejsów, które je poprzedzały. Tu podano wyjaśnienie odnoszące się
do wywołania openat(), jednak analogicznie można je zastosować do pozostałych interfejsów.
Przede wszystkim openat() pozwala uniknąć aplikacjom wystąpienia sytuacji wyścigu, która
może zachodzić przy otwieraniu za pomocą open() plików w katalogach innych, niż bieżący
katalog roboczy. Wyścig wynika z tego, że pewna składowa ścieżki podanej open() mogła ulec
zmianie równolegle z wywołaniem open(). Proszę założyć na przykład, że próbujemy utworzyć
plik kat1/kat2/xxx.zal, jeśli plik kat1/kat2/xxx istnieje. Jednak pomiędzy sprawdzeniem
istnienia i krokiem utworzenia pliku, kat1 lub kat2 (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 dirfd do (przykładowo) fstatat(2) i openat(). Użycie
deskryptora pliku dirfd ma także inne zalety:
• deskryptor pliku jest stabilną referencją do katalogu, nawet gdy jego nazwa się zmieni
oraz
• 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.
Po drugie, openat() pozwala na implementację „bieżącego katalogu roboczego” 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
/proc/self/fd/dirfd, lecz jest to mniej wydajne).
Argument dirfd do tych API można pozyskać za pomocą open() lub openat() do otworzenia
katalogu (ze znacznikiem O_RDONLY albo O_PATH). Alternatywnie, taki deskryptor pliku można
uzyskać stosując dirfd(3) do strumienia katalogu utworzonego za pomocą opendir(3).
W omawianych API, gdy poda się argument dirfd równy AT_FDCWD 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 flags, pozwalający na
dostęp do funkcjonalności, która nie jest dostępna w odpowiadającym im tradycyjnym API.
O_DIRECT
Znacznik O_DIRECT 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ść O_DIRECT również jest zróżnicowana; mogą one albo zawieść z błędem EINVAL,
albo awaryjnie skorzystać z buforowanego wejścia/wyjścia.
Od Linuksa 6.1, obsługa O_DIRECT i ograniczenia wyrównania związane z danym plikiem można
sprawdzić za pomocą statx(2), wykorzystując znacznik STATX_DIOALIGN. Obsługa
STATX_DIOALIGN różni się w zależności od systemu plików; więcej szczegółów w podręczniku
statx(2).
Niektóre systemy plików zapewniają swoje interfejsy do odpytywania ograniczeń wyrównania
O_DIRECT, przykładowo jest to operacja XFS_IOC_DIOINFO w xfsctl(3). Gdy jednak tylko jest
dostępny, należy korzystać z STATX_DIOALIGN.
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 BLKSSZGET ioctl(2) lub z powłoki, poleceniem:
blockdev --getss
Wejścia/wyjścia O_DIRECT nigdy nie należy uruchamiać równolegle z wywołaniem systemowym
fork(2), jeśli bufor pamięci jest przypisaniem prywatnym (obejmuje to wszystkie
przypisania utworzone za pomocą znacznika MAP_PRIVATE mmap(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 fork(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 O_DIRECT utworzono za pomocą shmat(2) lub mmap(2) ze
znacznikiem MAP_SHARED. Nie ma zastosowania również wtedy, gdy w stosunku do bufora
pamięci udzielono wskazówki MADV_DONTFORK za pomocą madvise(2), co zapewnia, że nie będzie
on dostępny dla potomka po wykonaniu fork(2).
Znacznik O_DIRECT wprowadzono w SGI IRIX, gdzie ograniczenia związane z wyrównaniem były
podobne do Linuksa 2.4. IRIX ma również wywołanie fcntl(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.
Obsługę O_DIRECT 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 open() zawiedzie z błędem EINVAL.
Aplikacje powinny unikać mieszania O_DIRECT 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 mmap(2) na
plikach, przy używaniu bezpośredniego wejścia/wyjścia do tych samych plików.
Zachowanie O_DIRECT 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 O_DIRECT
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 O_DIRECT. 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 O_DIRECT.
Podsumowując, O_DIRECT 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 O_DIRECT,
traktowały go jako, domyślnie wyłączoną, opcję poprawiającą wydajność.
USTERKI
Obecnie nie da się włączyć wejścia/wyjścia sterowanego sygnałem podając znacznik O_ASYNC
przy wywołaniu open(); należy użyć fcntl(2), aby włączyć ten znacznik.
Przy próbie określenia, czy jądro obsługuje funkcję O_TMPFILE, należy sprawdzać dwa różne
kody błędu: EISDIR i ENOENT.
Jeśli we flags poda się O_CREAT oraz O_DIRECTORY, a plik podany w ścieżce pathname nie
istnieje, open() utworzy zwykły plik (tj. O_DIRECTORY zostanie zignorowany).
ZOBACZ TAKŻE
chmod(2), chown(2), close(2), dup(2), fcntl(2), link(2), lseek(2), mknod(2), mmap(2),
mount(2), open_by_handle_at(2), openat2(2), read(2), socket(2), stat(2), umask(2),
unlink(2), write(2), fopen(3), acl(5), fifo(7), inode(7), path_resolution(7), symlink(7)
TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są: Przemek Borys
<pborys@dione.ids.pl>, Andrzej Krzysztofowicz <ankry@green.mf.pg.gda.pl> i Michał Kułach
<michal.kulach@gmail.com>
Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji
można uzyskać zapoznając się z GNU General Public License w wersji 3
⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ lub nowszej. Nie przyjmuje się ŻADNEJ
ODPOWIEDZIALNOŚCI.
Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej
⟨manpages-pl-list@lists.sourceforge.net⟩.