.\" -*- coding: UTF-8 -*-
.\" This manpage is Copyright (C) 1992 Drew Eckhardt;
.\" and Copyright (C) 1993 Michael Haardt, Ian Jackson;
.\" and Copyright (C) 1998 Jamie Lokier;
.\" and Copyright (C) 2002-2010, 2014 Michael Kerrisk;
.\" and Copyright (C) 2014 Jeff Layton
.\" and Copyright (C) 2014 David Herrmann
.\" and Copyright (C) 2017 Jens Axboe
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" Modified 1993-07-24 by Rik Faith <faith@cs.unc.edu>
.\" Modified 1995-09-26 by Andries Brouwer <aeb@cwi.nl>
.\" and again on 960413 and 980804 and 981223.
.\" Modified 1998-12-11 by Jamie Lokier <jamie@imbolc.ucc.ie>
.\" Applied correction by Christian Ehrhardt - aeb, 990712
.\" Modified 2002-04-23 by Michael Kerrisk <mtk.manpages@gmail.com>
.\"	Added note on F_SETFL and O_DIRECT
.\"	Complete rewrite + expansion of material on file locking
.\"	Incorporated description of F_NOTIFY, drawing on
.\"		Stephen Rothwell's notes in Documentation/dnotify.txt.
.\"	Added description of F_SETLEASE and F_GETLEASE
.\" Corrected and polished, aeb, 020527.
.\" Modified 2004-03-03 by Michael Kerrisk <mtk.manpages@gmail.com>
.\"     Modified description of file leases: fixed some errors of detail
.\"     Replaced the term "lease contestant" by "lease breaker"
.\" Modified, 27 May 2004, Michael Kerrisk <mtk.manpages@gmail.com>
.\"     Added notes on capability requirements
.\" Modified 2004-12-08, added O_NOATIME after note from Martin Pool
.\" 2004-12-10, mtk, noted F_GETOWN bug after suggestion from aeb.
.\" 2005-04-08 Jamie Lokier <jamie@shareable.org>, mtk
.\"	Described behavior of F_SETOWN/F_SETSIG in
.\"	multithreaded processes, and generally cleaned
.\"	up the discussion of F_SETOWN.
.\" 2005-05-20, Johannes Nicolai <johannes.nicolai@hpi.uni-potsdam.de>,
.\"	mtk: Noted F_SETOWN bug for socket file descriptor in Linux 2.4
.\"	and earlier.  Added text on permissions required to send signal.
.\" 2009-09-30, Michael Kerrisk
.\"     Note obsolete F_SETOWN behavior with threads.
.\"     Document F_SETOWN_EX and F_GETOWN_EX
.\" 2010-06-17, Michael Kerrisk
.\"	Document F_SETPIPE_SZ and F_GETPIPE_SZ.
.\" 2014-07-08, David Herrmann <dh.herrmann@gmail.com>
.\"     Document F_ADD_SEALS and F_GET_SEALS
.\" 2017-06-26, Jens Axboe <axboe@kernel.dk>
.\"     Document F_{GET,SET}_RW_HINT and F_{GET,SET}_FILE_RW_HINT
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH fcntl 2 "2 maja 2024 r." "Linux man\-pages 6.9.1" 
.SH NAZWA
fcntl \- manipuluje deskryptorem pliku
.SH BIBLIOTEKA
Standardowa biblioteka C (\fIlibc\fP, \fI\-lc\fP)
.SH SKŁADNIA
.nf
\fB#include <fcntl.h>\fP
.P
\fBint fcntl(int \fP\fIfd\fP\fB, int \fP\fIop\fP\fB, ... /* \fP\fIarg\fP\fB */ );\fP
.fi
.SH OPIS
\fBfcntl\fP dokonuje jednej z operacji opisanych poniżej na otwartym
deskryptorze pliku \fIfd\fP. Wykonywana operacja jest określona przez \fIop\fP.
.P
\fBfcntl\fP() opcjonalnie może przyjąć trzeci argument. To, czy argument ten
jest wymagany, zależy od \fIop\fP. Wymagany typ argumentu jest wskazany w
nawiasie po każdej nazwie \fIop\fP (zwykle wymaganym typem jest \fIint\fP, a
argument jest identyfikowany określeniem \fIarg\fP) lub podane jest \fIvoid\fP,
gdy argument nie jest wymagany.
.P
Niektóre z poniższych operacji są obsługiwane jedynie w określonej wersji
jądra Linux. Preferowaną metodą sprawdzenia, czy działające aktualnie jądro
obsługuje daną operację, jest przywołanie \fBfcntl\fP() z daną wartością \fIop\fP
i sprawdzenie, czy wywołanie zawiedzie z błędem \fBEINVAL\fP wskazując, że
jądro nie rozpoznało tej wartości.
.SS "Duplikowanie deskryptora pliku"
.TP 
\fBF_DUPFD\fP (\fIint\fP)
Duplikuje deskryptor pliku \fIfd\fP za pomocą najniższego dostępnego numeru
deskryptora pliku większego lub równego \fIarg\fP. Różni się to od \fBdup2\fP(2),
korzystającego z konkretnego, zadanego deskryptora.
.IP
Po pomyślnym zakończeniu zwracany jest nowy deskryptor pliku.
.IP
Więcej informacji znajduje się w podręczniku \fBdup\fP(2).
.TP 
\fBF_DUPFD_CLOEXEC\fP (\fIint\fP; od Linuksa 2.6.24)
Jak w przypadku \fBF_DUPFD\fP, lecz dodatkowo ustawia znacznik
zamknięcia\-przy\-wykonaniu dla duplikowanego deskryptora pliku. Podanie tego
znacznika umożliwia programowi na uniknięcie dodatkowej operacji \fBF_SETFD\fP
\fBfcntl\fP(), w celu ustawienia znacznika \fBFD_CLOEXEC\fP. Wyjaśnienie powodu,
dla którego znacznik ten jest przydatny, znajduje się w opisie \fBO_CLOEXEC\fP
w podręczniku \fBopen\fP(2).
.SS "Znaczniki deskryptora pliku"
Następujące operacje kontrolują znaczniki powiązane z deskryptorem
pliku. Obecnie zdefiniowano jedynie jeden taki znacznik: \fBFD_CLOEXEC\fP,
znacznik zamknięcia\-przy\-wykonaniu. Jeśli ustawiony jest bit \fBFD_CLOEXEC\fP,
to deskryptor pliku zostanie automatycznie zamknięty podczas pomyślnego
wykonania \fBexecve\fP(2) (jeśli \fBexecve\fP(2) zawiedzie, deskryptor pliku jest
pozostawiany otwarty). Jeśli bit \fBFD_CLOEXEC\fP nie jest ustawiony,
deskryptor pliku pozostanie otwarty podczas wykonania \fBexecve\fP(2).
.TP 
\fBF_GETFD\fP (\fIvoid\fP)
Zwraca (jako wynik funkcji) znaczniki deskryptora pliku; argument \fIarg\fP
jest ignorowany.
.TP 
\fBF_SETFD\fP (\fIint\fP)
Ustawia znaczniki deskryptora pliku na wartość określoną w \fIarg\fP.
.P
W programach wielowątkowych, użycie \fBF_SETFD\fP \fBfcntl\fP() do ustawienia
znacznika zamknięcia przy uruchomieniu w tym samym czasie, w którym inny
wątek wykonuje \fBfork\fP(2) i \fBexecve\fP(2) jest narażone na wystąpienie
sytuacji wyścigu, która może niezamierzenie prowadzić do wycieku deskryptora
pliku do programu wykonującego proces potomny. Szczegóły i sposób na
uniknięcie tego problemu opisano przy znaczniku \fBO_CLOEXEC\fP, w podręczniku
\fBopen\fP(2).
.SS "Znaczniki stanu pliku"
.\" or
.\" .BR creat (2),
Z każdym opisem otwartego pliku stowarzyszonych jest kilka znaczników
inicjowanych przez \fBopen\fP(2), które mogą ewentualnie być modyfikowane przez
\fBfcntl\fP(2). Zduplikowane deskryptory pliku (utworzone za pomocą \fBdup\fP(2),
\fBfork\fP(2), itp.) odnoszą się do tego samego opisu otwartego pliku, dzieląc
zatem te same znaczniki stanu pliku.
.P
Znaczniki stanu pliku i ich znaczenie są opisane w \fBopen\fP(2).
.TP 
\fBF_GETFL\fP (\fIvoid\fP)
Zwraca (jako wynik funkcji) tryb dostępu do pliku i znaczniki stanu pliku,
\fIarg\fP jest ignorowany.
.TP 
\fBF_SETFL\fP (\fIint\fP)
Ustawia znaczniki stanu pliku na wartości określone przez \fIarg\fP. W \fIarg\fP
ignorowane są: tryb dostępu do pliku (\fBO_RDONLY\fP, \fBO_WRONLY\fP, \fBO_RDWR\fP)
oraz znaczniki tworzenia pliku (tj. \fBO_CREAT\fP, \fBO_EXCL\fP, \fBO_NOCTTY\fP,
\fBO_TRUNC\fP). W Linuksie, operacja ta może zmienić jedynie znaczniki
\fBO_APPEND\fP, \fBO_ASYNC\fP, \fBO_DIRECT\fP, \fBO_NOATIME\fP i \fBO_NONBLOCK\fP. Nie da
się zmienić znaczników \fBO_DSYNC\fP i \fBO_SYNC\fP; zob. USTERKI niżej.
.SS "Blokowanie doradcze rekordów"
Linux implementuje tradycyjne (\[Bq]powiązane z procesem\[rq]) blokady
rekordów UNIX, zgodnie ze standardem POSIX. Istnieje również typowo
linuksowa alternatywa używająca lepszej semantyki \[em] blokady opisów
otwartego pliku, które są opisane nieco niżej.
.P
\fBF_SETLK\fP, \fBF_SETLKW\fP i \fBF_GETLK\fP służą do zakładania, zwalniania i
sprawdzania obecności blokad rekordów (znanych również jako blokady zakresu
bajtów, segmentów pliku lub obszarów pliku). Trzeci argument, \fIlock\fP, jest
wskaźnikiem do struktury zawierającej co najmniej następujące pola
(kolejność nie jest określona).
.P
.in +4n
.EX
struct flock {
    ...
    short l_type;    /* Rodzaj blokady: F_RDLCK,
                        F_WRLCK, F_UNLCK */
    short l_whence;  /* Sposób interpretacji l_start:
                        SEEK_SET, SEEK_CUR, SEEK_END */
    off_t l_start;   /* Początek (przesunięcie) blokady */
    off_t l_len;     /* Liczba blokowanych bajtów */
    pid_t l_pid;     /* PID procesu uniemożliwiającego blokadę
                        (ustawiane przez F_GETLK i F_OFD_GETLK) */
    ...
};
.EE
.in
.P
Pola \fIl_whence\fP, \fIl_start\fP i \fIl_len\fP w tej strukturze określają zakres
bajtów, które mają ulec zablokowaniu. Bajty po końcu pliku mogą być
blokowane, nie mogą to być natomiast bajty przed jego początkiem.
.P
\fIl_start\fP jest początkowym przesunięciem blokady i jest interpretowane w
odniesieniu do: początku pliku (gdy \fIl_whence\fP wynosi \fBSEEK_SET\fP),
bieżącego przesunięcia pliku (gdy \fIl_whence\fP wynosi \fBSEEK_CUR\fP) albo końca
pliku (gdy \fIl_whence\fP wynosi \fBSEEK_END\fP). W ostatnich dwóch przypadkach,
\fIl_start\fP może być liczbą ujemną zakładając, że przesunięcie nie prowadzi
przed początek pliku.
.P
\fIl_len\fP określa liczbę bajtów do zablokowania. Jeśli \fIl_len\fP jest
dodatnie, to przedział do zablokowania pokrywa bajty od \fIl_start\fP do
\fIl_start\fP+\fIl_len\fP\-1 włącznie. Podanie 0 w \fIl_len\fP ma specjalne znaczenie:
blokowane są wszystkie bajty od położenia określonego przez \fIl_whence\fP i
\fIl_start\fP, aż do końca pliku, niezależnie od tego, jak duży staje się plik.
.P
POSIX.1\-2001 zezwala implementacji (lecz tego nie wymaga) na obsługę
ujemnych wartości \fIl_len\fP; jeśli \fIl_len\fP jest ujemna, to przedział,
którego dotyczy \fIlock\fP obejmuje bajty od \fIl_start\fP+\fIl_len\fP do
\fIl_start\fP\-1 włącznie. Jest to obsługiwane od Linuksa 2.4.21 i Linuksa
2.5.49.
.P
Pole \fIl_type\fP może służyć do założenia blokady dla odczytu (\fBF_RDLCK\fP) lub
dla zapisu (\fBF_WRLCK\fP) do pliku. Dowolna liczba procesów może utrzymywać
blokadę dla odczytu pliku (blokada wspólna) w pewnym jego obszarze, ale
tylko jeden proces może utrzymywać blokadę dla zapisu do pliku (blokada
wyłączna). Blokada wyłączna wyklucza wszelkie inne blokady, zarówno wspólne,
jak i wyłączne. Pojedynczy proces może w danym obszarze pliku utrzymywać
blokadę tylko jednego rodzaju; gdy w aktualnie zablokowanym obszarze
zakładana jest nowa blokada, to istniejąca blokada jest przekształcana w
blokadę nowego typu (takie przekształcenie może pociągać za sobą podział,
skrócenie lub połączenie z istniejącą blokadą, gdy zakres bajtów podany dla
nowej blokady nie pokrywa się dokładnie z zakresem istniejącej blokady).
.TP 
\fBF_SETLK\fP (\fIstruct flock *\fP)
Ustawienie blokady dla zakresu bajtów określonego przez pola \fIl_whence\fP,
\fIl_start\fP i \fIl_len\fP \fIlock\fP (gdy \fBl_type\fP jest równe \fBF_RDLCK\fP lub
\fBF_WRLCK\fP) albo jej zwolnienie (gdy \fBl_type\fP jest równe \fBF_UNLCK\fP). Jeśli
kolidująca blokada jest utrzymywana przez inny proces, funkcja ta zwraca \-1
i ustawia  \fIerrno\fP na \fBEACCES\fP lub \fBEAGAIN\fP (zwracany w tym przypadku
błąd różni się pomiędzy implementacjami, dlatego POSIX wymaga sprawdzania
przez przenośne aplikacje obu wartości błędów).
.TP 
\fBF_SETLKW\fP (\fIstruct flock *\fP)
Podobne do \fBF_SETLK\fP, lecz w sytuacji, gdy na pliku założona jest
kolidująca blokada czeka na zwolnienie tej blokady. Jeśli podczas
oczekiwania zostanie przechwycony sygnał, funkcja jest przerywana i (po
powrocie z funkcji obsługi sygnału) powraca natychmiast (zwracając wartość
\-1 i ustawiając \fIerrno\fP na \fBEINTR\fP; zob. \fBsignal\fP(7)).
.TP 
\fBF_GETLK\fP (\fIstruct flock *\fP)
Jako argument \fIlock\fP tej funkcji określa blokadę, jaką chcielibyśmy założyć
na pliku. Gdy założenie blokady jest możliwe, \fBfcntl\fP() w rzeczywistości
jej nie zakłada, lecz zwraca \fBF_UNLCK\fP w polu \fIl_type\fP struktury \fIlock\fP
pozostawiając inne pola tej struktury niezmienione.
.IP
Jeśli jedna lub więcej niezgodnych blokad zapobiegłoby umieszczeniu tej
blokady, to \fBfcntl\fP() zwróci szczegóły o jednej z tych blokad w polach
\fIl_type\fP, \fIl_whence\fP, \fIl_start\fP i \fIl_len\fP w \fIlock\fP. Jeśli niezgodna
blokada jest tradycyjną (związaną z procesem) blokadą rekordu, to pole
\fIl_pid\fP jest ustawiane na PID procesu utrzymującego tę blokadę. Jeśli
niezgodna blokada jest blokadą opisu otwartego pliku (OFD), to \fIl_pid\fP jest
ustawiane na \-1. Proszę zauważyć, że w momencie sprawdzenia zwracanych
informacji przez wywołującego, mogą być już one nieaktualne.
.P
Aby założyć blokadę do odczytu, deskryptor \fIfd\fP musi być otwarty do
odczytu. Aby założyć blokadę do zapisu, deskryptor \fIfd\fP musi być otwarty do
zapisu. Aby założyć obydwa rodzaje blokad, należy otworzyć plik do odczytu i
zapisu.
.P
Przy umieszczaniu blokady z \fBF_SETLKW\fP, jądra wykrywa \fIzakleszczenia\fP, gdy
żądania blokad dwóch lub więcej procesów są wzajemnie zablokowane przez
blokady utrzymywane przez inne procesy. Przykładowo, przypuśćmy, że proces A
utrzymuje blokadę zapisu na bajcie 100. pliku, a proces B utrzymuje blokadę
zapisu na bajcie 200. Jeśli każdy z procesów spróbuje następnie zablokować
bajt już zablokowany przez drugie proces za pomocą \fBF_SETLKW\fP, to \[em] bez
wykrywania zakleszczeń \[em] oba procesy pozostałyby stale
zablokowane. Jeśli jądro wykryje takie zakleszczenie, to spowoduje
natychmiastowe niepowodzenie jednego z żądań blokady, z błędem \fBEDEADLK\fP;
aplikacja napotykająca na taki błąd powinna zwolnić niektóre ze swoich
blokad, aby pozwolić działać inny aplikacjom, przed ponowną próbą odzyskania
wymaganych blokad. Wykrywane są również koliste zakleszczenia, z więcej niż
dwoma procesami. Proszę jednak zauważyć, że algorytm wykrywania zakleszczeń
jądra ma swoje ograniczenia, zob. USTERKI.
.P
Oprócz usunięcia za pomocą wyraźnego \fBF_UNLCK\fP, blokady rekordów są
zwalniane automatycznie po zakończeniu procesu.
.P
Blokady rekordów nie są dziedziczone przez procesy potomne poprzez
\fBfork\fP(2), ale są zachowywane poprzez \fBexecve\fP(2).
.P
Ze względu na wykonywane przez bibliotekę \fBstdio\fP(3) buforowanie, należy
unikać blokowania rekordów w połączeniu z funkcjami z tego pakietu; zamiast
tego należy używać \fBread\fP(2) i \fBwrite\fP(2).
.P
Opisane wyżej blokady rekordów są związane z procesem (w przeciwieństwie do
blokad opisu otwartego pliku, opisanych niżej). Ma to pewne niefortunne
konsekwencje:
.IP \[bu] 3
.\" (Additional file descriptors referring to the same file
.\" may have been obtained by calls to
.\" .BR open "(2), " dup "(2), " dup2 "(2), or " fcntl ().)
Jeśli proces zamknie \fIdowolny\fP deskryptor odnoszący się do pliku, to
zwalniane są wszystkie blokady, niezależnie od tego, na którym z
deskryptorów pliku blokady te uzyskano. Jest to złe: oznacza, że proces może
utracić swe blokady na pliku takim jak \fI/etc/passwd\fP lub \fI/etc/mtab\fP gdy
jakaś funkcja biblioteczna zdecyduje się z jakiegoś powodu otworzyć,
odczytać i zamknąć ten sam plik.
.IP \[bu]
Wątki procesu dzielą blokady. Innymi słowy, program wielowątkowy nie może
korzystać z blokad rekordów, aby uniemożliwić jednoczesny dostęp do tego
samego miejsca pliku przez swoje wątki.
.P
Blokady opisu otwartego pliku rozwiązują oba te problemy.
.SS "Blokady opisu otwartego pliku (spoza POSIX)"
.\" FIXME . Review progress into POSIX
.\" http://austingroupbugs.net/view.php?id=768
Blokady opisu otwartego pliku są blokadami doradczymi, definiowanymi w
zakresie bajtów, których działanie jest w większości identyczne do
tradycyjnych blokad rekordów opisanych wyżej. Ten typ blokad jest typowo
linuksowy i jest dostępny od Linuksa 3.15 (w Austin Group istnieje
propozycja włączenia tego typu blokady do następnej rewizji
POSIX.1). Wyjaśnienie opisu otwartego pliku znajduje się w podręczniku
\fBopen\fP(2).
.P
Podstawową różnicą, pomiędzy dwoma typami blokad jest fakt, że o ile
tradycyjne blokady rekordów są związane z procesem, to blokady opisu
otwartego pliku są związane z opisem otwartego pliku, na którym je uzyskano,
podobnie jak to wygląda w przypadku blokad uzyskanych za pomocą
\fBflock\fP(2). W efekcie (inaczej niż przy tradycyjnych blokadach doradczych
rekordów) blokady opisu otwartego pliku są dziedziczone przy \fBfork\fP(2) (i
\fBclone\fP(2) ze znacznikiem \fBCLONE_FILES\fP), a także są automatycznie
zwalniane po ostatnim zamknięciu opisu otwartego pliku, zamiast zwalniania
przy jakimkolwiek zamknięciu pliku.
.P
Kolidujące kombinacje blokad (tj. blokada odczytu z blokadą zapisu lub dwie
blokady zapisu) gdy jedna blokada jest blokadą opisu otwartego pliku, a
druga jest tradycyjną blokadą rekordu prowadzą do konfliktu nawet wówczas,
gdy są uzyskane przez ten sam proces na tym samym deskryptorze pliku.
.P
Blokady opisu otwartego pliku umieszczone na tym samym opisie otwartego
pliku (tj. za pomocą tego samego deskryptora pliku lub za pomocą duplikatu
deskryptora pliku utworzonego przez \fBfork\fP(2), \fBdup\fP(2), \fBF_DUPFD\fP z
\fBfcntl\fP() itp.) są zawsze kompatybilne: jeśli nowa blokada jest umieszczona
na już zablokowanym rejonie pliku, to istniejące blokada jest konwertowana
na nowy typ blokady (takie konwersje mogą prowadzić to podziału,
zmniejszenia lub złączenia z dotychczasową blokadą, jak opisano to wyżej)
.P
Z drugiej strony, blokady opisu otwartego pliku mogą być w konflikcie, gdy
są uzyskane przez różne opisy otwartego pliku. Z tego względu, program
wielowątkowy może korzystać z blokad opisu otwartego pliku do
synchronizowania dostępu do jakiegoś miejsca w pliku, otwierając
(\fBopen\fP(2)) plik z różnych wątków i zakładając blokady za pomocą wynikowego
deskryptora pliku.
.P
Podobnie jak w przypadku tradycyjnych blokad doradczych, trzeci argument do
\fBfcntl\fP() \[em] \fIlock\fP, jest wskaźnikiem do struktury \fIflock\fP. W
odróżnieniu do tradycyjnych blokad rekordów, pole \fIl_pid\fP tej struktury
musi być ustawione na zero za pomocą operacji opisanych niżej.
.P
Operacje działające z blokadami opisu otwartego pliku są analogiczne do tych
używanych z tradycyjnymi blokadami:
.TP 
\fBF_OFD_SETLK\fP (\fIstruct flock *\fP)
Ustawia blokadę opisu otwartego pliku (gdy \fBl_type\fP jest równe \fBF_RDLCK\fP
lub \fBF_WRLCK\fP) albo zwalnia blokadę opisu otwartego pliku (gdy \fBl_type\fP
jest równe \fBF_UNLCK\fP) dla zakresu bajtów określonego przez pola
\fIl_whence\fP, \fIl_start\fP i \fIl_len\fP \fIlock\fP. Jeśli kolidująca blokada jest
utrzymywana przez inny proces, funkcja ta zwraca \-1 i ustawia \fIerrno\fP na
\fBEAGAIN\fP.
.TP 
\fBF_OFD_SETLKW\fP (\fIstruct flock *\fP)
Podobne do \fBF_SETLK\fP, lecz w sytuacji, gdy na pliku założona jest
kolidująca blokada, czeka na zwolnienie tej blokady. Jeśli podczas
oczekiwania zostanie przechwycony sygnał, funkcja jest przerywana i (po
powrocie z funkcji obsługi sygnału) powraca natychmiast (zwracając wartość
\-1 i ustawiając \fIerrno\fP na \fBEINTR\fP; zob. \fBsignal\fP(7)).
.TP 
\fBF_OFD_GETLK\fP (\fIstruct flock *\fP)
Jako argument \fIlock\fP tej funkcji określa blokadę opisu otwartego pliku,
jaką chcielibyśmy założyć na pliku. Gdy założenie blokady jest możliwe,
\fBfcntl\fP() w rzeczywistości jej nie zakłada, lecz zwraca \fBF_UNLCK\fP w polu
\fIl_type\fP struktury \fIlock\fP pozostawiając inne pola tej struktury
niezmienione. Jeśli co najmniej jedna niezgodna blokada uniemożliwiłaby
założenie zadanej blokady, to informacje o jednej z tych blokad są zwracane
za pomocą \fIlock\fP, jak to opisano powyżej dla \fBF_GETLK\fP.
.P
.\" commit 57b65325fe34ec4c917bc4e555144b4a94d9e1f7
.\"
W bieżącej implementacji, dla blokad opisu otwartego pliku nie zachodzi
wykrywanie zakleszczeń (w odróżnieniu od blokad rekordów związanych z
procesem, dla których jądro wykonuje wykrywanie zakleszczeń).
.SS "Blokowanie obowiązujące (przymusowe)"
\fIOstrzeżenie\fP: linuksowa implementacja blokowania obowiązującego jest
zawodna (zob. USTERKI poniżej). Z powodu opisanych błędów i faktu, że
funkcjonalność ta nie była często wykorzystywana, od Linuksa 4.5, tego typu
blokowanie stało się opcjonalne i zależy od ustawienia opcji konfiguracyjnej
(\fBCONFIG_MANDATORY_FILE_LOCKING\fP). Od Linuksa 5.15 blokowanie obowiązujące
(przymusowe) nie jest już w ogólne obsługiwane.
.P
Domyślnie, zarówno tradycyjne blokady (związane z procesem) jak i blokady
opisu otwartego pliku (OFD) są doradcze. Blokady doradcze nie są wymuszane i
są przydatne tylko w przypadku współdziałających procesów.
.P
Oba te typy mogą być również obowiązujące. Blokady obowiązujące są wymuszane
dla wszystkich procesów. Jeśli proces spróbuje uzyskać niezgodny dostęp
(tj. odczyt \[em] \fBread\fP(2) lub zapis \[em] \fBwrite\fP(2)) w obszarze pliku,
który posiada niezgodną blokadę obowiązującą, to wynik zależy od tego, czy
dla jego opisu otwartego pliku włączono znacznik \fBO_NONBLOCK\fP. Jeśli
znacznik \fBO_NONBLOCK\fP nie jest włączony, to dane wywołanie systemowe jest
blokowane do momentu usunięcia blokady lub jej przekształcenia w tryb, który
jest zgodny z uzyskiwanym dostępem. Jeśli znacznik \fBO_NONBLOCK\fP jest
włączony, to wywołanie systemowe zawodzi z błędem \fBEAGAIN\fP.
.P
Aby skorzystać z obowiązujących blokad, blokowanie obowiązujące musi być
włączone zarówno na systemie plików zawierającym blokowany plik, jak i na
samym pliku. Blokowanie obowiązujące w systemie plików włącza się za pomocą
opcji \[Bq]\-o mand\[rq] programu \fBmount\fP(8) lub za pomocą znacznika
\fBMS_MANDLOCK\fP do \fBmount\fP(8). Blokowanie obowiązujące na pliku włącza się
poprzez wyłączenie prawa uruchamiania dla grupy i włączenie bitu
set\-group\-ID (zob. \fBchmod\fP(1) i \fBchmod\fP(2)).
.P
.\"
Blokowanie obowiązujące nie jest określone normą POSIX. Niektóre inne
systemy również obsługują blokowanie obowiązujące, choć szczegóły ich
włączenia również się między systemami.
.SS "Zagubione blokady"
Gdy blokada doradcza jest uzyskiwana na sieciowym systemie plików, takim jak
NFS, możliwe jest zagubienie blokady. Może się tak stać ze względu na
działanie administracyjne na serwerze lub z powodu podziału sieci
(tzn. utraty połączenie z serwerem), które będzie trwało na tyle długo, że
serwer może przyjąć brak dalszego funkcjonowania przez klienta.
.P
.\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d
Gdy system plików stwierdzi, że blokada została zagubiona, przyszły odczyt
(\fBread\fP(2)) lub zapis (\fBwrite\fP(2)) może zawieść z błędem \fBEIO\fP. Błąd ten
będzie występował do momentu usunięcia blokady lub zamknięcia deskryptora
pliku. Od Linuksa 3.12, dzieje się tak przynajmniej w NFSv4 (we wszystkich
jego pomniejszych wydaniach).
.P
.\"
Niektóre wersje Uniksa wysyłają w takiej sytuacji sygnał (\fBSIGLOST\fP). Linux
nie definiuje tego sygnału i nie zapewnia żadnego asynchronicznego
powiadamiania o zagubionych blokadach.
.SS "Zarządzanie sygnałami"
\fBF_GETOWN\fP, \fBF_SETOWN\fP, \fBF_GETOWN_EX\fP, \fBF_SETOWN_EX\fP, \fBF_GETSIG\fP i
\fBF_SETSIG\fP służą do zarządzania sygnałami dostępności wejścia/wyjścia:
.TP 
\fBF_GETOWN\fP (\fIvoid\fP)
Zwraca (jako wynik funkcji) identyfikator procesu lub identyfikator grupy
procesów aktualnie otrzymujących sygnały \fBSIGIO\fP i \fBSIGURG\fP dla zdarzeń na
deskryptorze plików \fIfd\fP. Identyfikatory procesów są zwracane jako wartości
dodatnie, identyfikatory grupy procesów są zwracane jako wartości ujemne
(lecz zob. USTERKI poniżej). \fIarg\fP jest ignorowane.
.TP 
\fBF_SETOWN\fP (\fIint\fP)
Ustawia identyfikator procesu lub identyfikator grupy procesów aktualnie
otrzymujących sygnały \fBSIGIO\fP i \fBSIGURG\fP dla zdarzeń na deskryptorze
plików \fIfd\fP. Docelowy identyfikator procesu lub grupy procesów podaje się
jako \fIarg\fP. Identyfikator procesu jest określany jako liczba dodatnia;
identyfikator grupy procesów jest określany za pomocą wartości
ujemnych. Najczęściej, proces wywołujący określa się jako właściciel
(tj. \fIarg\fP jest podawany jak przez \fBgetpid\fP(2)).
.IP
Oprócz ustawiania właściciela deskryptora pliku, konieczne jest również
włączenie generowania sygnałów na deskryptorze plików. Można to uczynić za
pomocą operacji \fBF_SETFL\fP \fBfcntl\fP(), ustawiając znacznik stanu pliku
\fBO_ASYNC\fP na deskryptorze pliku. Co za tym idzie, gdy tylko na deskryptorze
pliku możliwe stanie się wejście lub wyjście, zostanie wysłany sygnał
\fBSIGIO\fP. Operację \fBF_SETSIG\fP \fBfcntl\fP() można wykorzystać do uzyskania
dostarczenia sygnału innego niż \fBSIGIO\fP.
.IP
Wysłanie sygnału do właściciela procesu (grupy) podanego w \fBF_SETOWN\fP,
podlega takim samym sprawdzeniom uprawnień jak opisano w przypadku
\fBkill\fP(2), gdy proces wysyłający jest tym, który używa \fBF_SETOWN\fP (lecz
zob. USTERKI poniżej). Jeśli sprawdzenie uprawnień się nie powiedzie, to
sygnał jest po cichu odrzucany. \fIUwaga\fP: Operacja \fBF_SETOWN\fP sprawdza
poświadczenia wywołującego w chwili wywołania \fBfcntl\fP() i to te zapisane
poświadczenia są używane do sprawdzenia uprawnień.
.IP
.\" The following appears to be rubbish.  It doesn't seem to
.\" be true according to the kernel source, and I can write
.\" a program that gets a terminal-generated SIGIO even though
.\" it is not the foreground process group of the terminal.
.\" -- MTK, 8 Apr 05
.\"
.\" If the file descriptor
.\" .I fd
.\" refers to a terminal device, then SIGIO
.\" signals are sent to the foreground process group of the terminal.
Jeśli deskryptor pliku \fIfd\fP odnosi się do gniazda, \fBF_SETOWN\fP określa
również odbiorcę sygnałów \fBSIGURG\fP dostarczanych gdy poprzez gniazdo
przybędą dane autonomiczne (\fBSIGURG\fP jest wysyłany w sytuacjach, w których
\fBselect\fP(2) zgłosiłby \[Bq]stan wyjątkowy\[rq]).
.IP
Następujący akapit był prawdziwy w Linuksie 2.6.x do Linuksa 2.6.11
włącznie:
.RS
.IP
.\" The relevant place in the (2.6) kernel source is the
.\" 'switch' in fs/fcntl.c::send_sigio_to_task() -- MTK, Apr 2005
.\" send_sigurg()/send_sigurg_to_task() bypasses
.\" kill_fasync()/send_sigio()/send_sigio_to_task()
.\" to directly call send_group_sig_info()
.\"	-- MTK, Apr 2005 (kernel 2.6.11)
Jeśli \fBF_SETSIG\fP przekaże się wartość niezerową w procesie wielowątkowym,
działającym z biblioteką wątkowania obsługującą grupy wątków (np. NPTL), to
wartość pozytywna przekazana \fBF_SETOWN\fP ma inne znaczenie: zamiast byciem
identyfikatorem całego procesu, jest identyfikatorem wątku, który
identyfikuje dany wątek procesu. W efekcie, może być konieczne podanie
\fBF_SETOWN\fP wyniku \fBgettid\fP(2), zamiast wyniku \fBgetpid\fP(2), aby uzyskać
rozsądne wyniki, gdy korzysta się z \fBF_SETSIG\fP (w bieżącej, linuksowej
implementacji wątkowania, identyfikator głównego wątku jest taki sam jak
jego identyfikator procesu; oznacza to, że programy jednowątkowe mogą w tym
scenariuszu korzystać z \fBgettid\fP(2) lub \fBgetpid\fP(2)). Proszę jednak
zauważyć, że stwierdzenie w  tym akapicie nie dotyczy sygnału \fBSIGURG\fP,
wygenerowanego dla danych spoza pasma (ang. out\-of\-band data) na gnieździe:
ten sygnał zawsze trafia albo do procesu albo do grupy procesu, w zależności
od wartości przekazanej \fBF_SETOWN\fP.
.RE
.IP
Powyższe zachowanie przypadkowo porzucono w Linuksie 2.6.12 i nie zostanie
przywrócone. Od Linuksa 2.6.32, należy użyć \fBF_SETOWN_EX\fP, aby przeznaczyć
sygnały \fBSIGIO\fP do określonego wątku.
.TP 
\fBF_GETOWN_EX\fP (\fIstruct f_owner_ex *\fP) (od Linuksa 2.6.32)
Zwraca ustawienia aktualnego właściciela deskryptora pliku, jak zdefiniowane
poprzednią operacją \fBF_SETOWN_EX\fP. Informacja ta jest zwracana przez
strukturę na którą wskazuje \fIarg\fP, która ma postać:
.IP
.in +4n
.EX
struct f_owner_ex {
    int   type;
    pid_t pid;
};
.EE
.in
.IP
Pole \fItype\fP będzie miało jedną z wartości: \fBF_OWNER_TID\fP, \fBF_OWNER_PID\fP
lub \fBF_OWNER_PGRP\fP. Pole \fIpid\fP jest liczbą dodatnią, reprezentującą
identyfikator, odpowiednio, wątku, procesu lub grupy procesu. Więcej
informacji przy \fBF_SETOWN_EX\fP.
.TP 
\fBF_SETOWN_EX\fP (\fIstruct f_owner_ex *\fP) (od Linuksa 2.6.32)
Operacja przeprowadza podobne zadanie do \fBF_SETOWN\fP. Pozwala wywołującemu,
na kierowanie sygnałów o dostępności wejścia/wyjścia do określonego wątku,
procesu lub grupy procesu. Wywołujący określa cel sygnału za pomocą \fIarg\fP,
wskaźnika do struktury \fIf_owner_ex\fP. Pole \fItype\fP ma jedną z następujących
wartości, definiujących sposób interpretacji \fIpid\fP:
.RS
.TP 
\fBF_OWNER_TID\fP
Wysyła sygnał do wątku, którego identyfikator wątku (taki, jak zwracany
przez wywołanie \fBclone\fP(2) lub \fBgettid\fP(2)) podano w \fIpid\fP.
.TP 
\fBF_OWNER_PID\fP
Wysyła sygnał do procesu, którego identyfikator podano w \fIpid\fP.
.TP 
\fBF_OWNER_PGRP\fP
Wysyła sygnał do grupy procesu, której identyfikator podano w \fIpid\fP (proszę
zauważyć, że w przeciwieństwie do \fBF_SETOWN\fP, identyfikator grupy procesu
jest tu podawany jako wartość dodatnia).
.RE
.TP 
\fBF_GETSIG\fP (\fIvoid\fP)
Zwraca (jako wynik funkcji) sygnał wysyłany, gdy wejście lub wyjście stanie
się możliwe. Wartość zerowa oznacza wysyłanie \fBSIGIO\fP. Dowolna inna wartość
(łącznie z \fBSIGIO\fP) stanowi numer sygnału wysyłanego zamiast niego. W tych
sytuacjach dodatkowe informacje mogą być dostępne dla programu obsługi
sygnału, o ile zostały zainstalowane z użyciem \fBSA_SIGINFO\fP. \fIarg\fP jest
ignorowane.
.TP 
\fBF_SETSIG\fP (\fIint\fP)
.\"
.\" The following was true only up until Linux 2.6.11:
.\"
.\" Additionally, passing a nonzero value to
.\" .B F_SETSIG
.\" changes the signal recipient from a whole process to a specific thread
.\" within a process.
.\" See the description of
.\" .B F_SETOWN
.\" for more details.
Ustawia sygnał wysyłany, gdy wejście lub wyjście stanie się możliwe na
wartość podaną w \fIarg\fP. Wartość zerowa oznacza wysyłanie sygnału
domyślnego, czyli \fBSIGIO\fP. Dowolna inna wartość (łącznie z \fBSIGIO\fP)
stanowi numer sygnału wysyłanego zamiast niego. W tych sytuacjach dodatkowe
informacje mogą być dostępne dla programu obsługi sygnału, o ile zostały
zainstalowane z użyciem \fBSA_SIGINFO\fP.
.IP
Za pomocą \fBF_SETSIG\fP z niezerową wartością i przy ustawionym \fBSA_SIGINFO\fP
dla programu obsługi sygnału (patrz \fBsigaction\fP(2)), można przekazać do
programu obsługi sygnału w strukturze \fIsiginfo_t\fP dodatkowe informacje o
zdarzeniach wejścia/wyjścia. Jeśli pole \fIsi_code\fP wskazuje, że źródłem jest
\fBSI_SIGIO\fP, to pole \fIsi_fd\fP zawiera deskryptor pliku związany ze
zdarzeniem. W przeciwnym przypadku, brak jest wskazania, które deskryptory
plików oczekują i do określenia dostępnych dla wejścia/wyjścia deskryptorów
plików należy używać zwykłych mechanizmów (\fBselect \fP(2), \fBpoll\fP(2),
\fBread\fP(2) z ustawionym \fBO_NONBLOCK\fP itd.).
.IP
Proszę zauważyć, że deskryptor pliku udostępniony w \fIsi_fd\fP jest tym samym,
który podano podczas operacji \fBF_SETSIG\fP. To może prowadzić do nietypowej
sytuacji. Gdy deskryptor pliku jest duplikowany (\fBdup\fP(2) lub podobne), a
pierwotny deskryptor pliku jest zamykany, to zdarzenie wejście/wyjścia wciąż
będzie tworzone, lecz pole \fIsi_fd\fP będzie zawierać deskryptor już
zamkniętego pliku.
.IP
Wybierając sygnał czasu rzeczywistego (wartość >= \fBSIGRTMIN\fP), można,
używając tych samych numerów sygnałów, spowodować umieszczenie w kolejce
wielu zdarzeń wejścia/wyjścia (kolejkowanie zależy od dostępnej
pamięci). Jak powyżej, dodatkowe informacje są dostępne, gdy programy
obsługi sygnałów zostały zainstalowane z ustawionym \fBSA_SIGINFO\fP.
.IP
.\" See fs/fcntl.c::send_sigio_to_task() (2.4/2.6) sources -- MTK, Apr 05
Proszę zauważyć, że Linux narzuca limit liczby sygnałów czasu rzeczywistego,
które mogą oczekiwać w kolejce na proces (zob. \fBgetrlimit\fP(2) i
\fBsignal\fP(7)) i jeśli limit ten zostanie osiągnięty, to jądro powraca do
dostarczania \fBSIGIO\fP, a sygnał ten jest dostarczany do całego procesu,
zamiast to konkretnego wątku.
.P
Za pomocą tych mechanizmów program może zaimplementować w pełni
asynchroniczne wejście/wyjście, nie używając przez większość czasu
\fBselect\fP(2) i \fBpoll\fP(2).
.P
Opisane powyżej korzystanie z \fBO_ASYNC\fP jest specyficzne dla BSD i
Linuksa. Jedynym użyciem \fBF_GETOWN\fP i \fBF_SETOWN\fP podanym w POSIX.1 jest
użycie ich w połączeniu z sygnałem \fBSIGURG\fP na gniazdach (POSIX nie określa
sygnału \fBSIGIO\fP). \fBF_GETOWN_EX\fP, \fBF_SETOWN_EX\fP, \fBF_GETSIG\fP i \fBF_SETSIG\fP
są typowo linuksowe. POSIX posiada asynchroniczne wejście/wyjście i
strukturę \fIaio_sigevent\fP służącą do podobnych celów; w Linuksie są one
również dostępne jako część biblioteki GNU C (glibc).
.SS Dzierżawy
\fBF_SETLEASE\fP i \fBF_GETLEASE\fP (od Linuksa 2.4 wzwyż) służą do ustanowienia
nowe dzierżawy i pobrania aktualnej dzierżawy na opisie otwartego pliku, do
którego odnosi się deskryptor pliku \fIfd\fP. Dzierżawa pliku zapewnia
mechanizm, w którym proces utrzymujący dzierżawę (\[Bq]dzierżawca\[rq]) jest
zawiadamiany (poprzez dostarczenie sygnału) o tym, że inny proces
(\[Bq]zrywający dzierżawę\[rq]) próbuje wykonać \fBopen\fP(2) lub
\fBtruncate\fP(2) na pliku, do którego odnosi się dany deskryptor pliku.
.TP 
\fBF_SETLEASE\fP (\fIint\fP)
Ustawia lub usuwa dzierżawę pliku w zależności od tego, która z
następujących wartości zostanie podana jako argument \fIarg\fP typu integer :
.RS
.TP 
\fBF_RDLCK\fP
.\" The following became true in Linux 2.6.10:
.\" See the man-pages-2.09 Changelog for further info.
Ustanawia dzierżawę odczytu. Spowoduje to zawiadamianie procesu wywołującego
o otwarciu pliku do zapisu lub o obcinaniu go. Dzierżawa odczytu może zostać
nałożona na deskryptor pliku tylko wtedy, gdy jest on otwarty tylko do
odczytu.
.TP 
\fBF_WRLCK\fP
Ustanawia dzierżawę zapisu. Spowoduje to zawiadamianie wywołującego o
otwarciu pliku do odczytu lub do zapisu, lub o obcinaniu go. Dzierżawa
zapisu może zostać nałożona na plik tylko wtedy, gdy plik nie posiada
żadnych innych otwartych deskryptorów pliku.
.TP 
\fBF_UNLCK\fP
Zdejmuje własną dzierżawę z pliku.
.RE
.P
Dzierżawy są związane z opisem otwartego pliku (zob. \fBopen\fP(2)). Oznacza
to, że zduplikowane deskryptory pliku (utworzone np. za pomocą \fBfork\fP(2)
lub \fBdup\fP(2)) odnoszą się do tej samem dzierżawy i można ją zmodyfikować
lub zwolnić za pomocą dowolnego z tych deskryptorów. Co więcej, dzierżawa
jest zwalniana przez operację \fBF_UNLCK\fP na dowolnym z tych zduplikowanych
deskryptorów plików albo gdy wszystkie takie deskryptory pliku zostaną
zamknięte.
.P
Dzierżawy można ustanawiać tylko na zwykłych plikach. Proces
nieuprzywilejowany może ustanawiać jedynie dzierżawy na plikach, których UID
(właściciela) odpowiada UID\-owi systemu plików dla danego procesu. Proces z
przywilejem \fBCAP_LEASE\fP (ang. capability) może ustanawiać dzierżawy na
dowolnych plikach.
.TP 
\fBF_GETLEASE\fP (\fIvoid\fP)
Wskazuje rodzaj dzierżawy związanej z deskryptorem pliku \fIfd\fP, zwracając
\fBF_RDLCK\fP, \fBF_WRLCK\fP, albo \fBF_UNLCK\fP, wskazując (odpowiednio) dzierżawę:
odczytu, zapisu lub brak dzierżawy. \fIarg\fP jest ignorowane.
.P
Gdy proces (\[Bq]zrywający dzierżawę\[rq]) wykona operację \fBopen\fP(2) lub
\fBtruncate\fP(2) kolidującą z dzierżawą ustanowioną poprzez \fBF_SETLEASE\fP,
wywołanie funkcji systemowej jest blokowane przez jądro, a jądro zawiadamia
dzierżawcę poprzez wysłanie sygnału (domyślnie \fBSIGIO\fP). Dzierżawca
powinien odpowiedzieć na otrzymanie tego sygnału wykonując porządki
niezbędne dla przygotowania pliku do dostępu przez inny proces
(np. zrzucenie buforów) a następnie usunięcie lub zmniejszenie swojej
dzierżawy. Dzierżawa jest usuwana poprzez wykonanie operacji \fBF_SETLEASE\fP
podając jako \fIarg\fP \fBF_UNLCK\fP. Jeśli dzierżawca aktualnie utrzymuje
dzierżawę zapisu na pliku, a zrywający dzierżawę otwiera plik do odczytu, to
wystarczające jest zmniejszenie dzierżawy przez dzierżawcę do dzierżawy
odczytu. Dokonuje się tego poprzez wykonanie operacji \fBF_SETLEASE\fP podając
jako \fIarg\fP \fBF_RDLCK\fP.
.P
Jeśli dzierżawca nie zmniejszy lub nie zwolni dzierżawy w ciągu podanej w
\fI/proc/sys/fs/lease\-break\-time\fP liczby sekund, to jądro przymusowo usunie
lub zmniejszy dzierżawę dzierżawcy.
.P
Po zainicjowaniu zerwania dzierżawy, \fBF_GETLEASE\fP zwraca docelowy typ
dzierżawy (\fBF_RDLCK\fP albo \fBF_UNLCK\fP, w zależności od tego, co byłoby
zgodne ze zrywającym dzierżawę) do momentu, gdy dzierżawca dobrowolnie nie
zmniejszy lub nie zwolni dzierżawy albo do momentu, gdy jądro tego nie
wymusi po upłynięciu czasu zerwania dzierżawy.
.P
Po dobrowolnym lub wymuszonym usunięciu lub zmniejszeniu dzierżawy, przy
założeniu, że wywołanie funkcji systemowej przez zrywającego dzierżawę nie
jest nieblokujące, jądro pozwala na kontynuację funkcji systemowej wywołanej
przez zrywającego dzierżawę.
.P
Jeśli zablokowane wywołanie \fBopen\fP(2) lub \fBtruncate\fP(2) zrywającego
dzierżawę zostanie przerwane przez procedurę obsługi sygnału, to wywołanie
systemowe zawiedzie z błędem \fBEINTR\fP, lecz inne kroki opisane wyżej, wciąż
zostaną przeprowadzone. Jeśli zrywający dzierżawę zostanie zabity sygnałem w
trakcie blokowania \fBopen\fP(2) lub \fBtruncate\fP(2), to inne kroki opisane
wyżej, wciąż zostaną przeprowadzone. Jeśli zrywający dzierżawę poda znacznik
\fBO_NONBLOCK\fP przy wywoływaniu \fBopen\fP(2), to wywołanie zawiedzie
natychmiast z błędem \fBEWOULDBLOCK\fP, lecz inne kroki opisane wyżej, wciąż
zostaną przeprowadzone.
.P
Domyślnym sygnałem stosowanym do zawiadamiania dzierżawcy jest \fBSIGIO\fP,
lecz można go zmienić za pomocą operacji \fBF_SETSIG\fP w \fBfcntl\fP(). Jeśli
wydano operację \fBF_SETSIG\fP (nawet podając \fBSIGIO\fP), a funkcja obsługi
sygnału została określona za pomocą \fBSA_SIGINFO\fP, to ta funkcja obsługi
otrzyma jako drugi argument strukturę \fIsiginfo_t\fP, której pole \fIsi_fd\fP
będzie zawierać deskryptor pliku dzierżawionego pliku, do którego uzyskuje
dostęp inny proces (jest to przydatne, gdy wywołujący utrzymuje dzierżawy na
wielu plikach).
.SS "Powiadamianie o zmianach pliku lub katalogu (dnotify)"
.TP 
\fBF_NOTIFY\fP (\fIint\fP)
(od Linuksa 2.4 wzwyż) Zapewnia powiadamianie o modyfikacji katalogu, do
którego odnosi się \fIfd\fP lub o modyfikacji któregokolwiek z plików w tym
katalogu. Zdarzenia, powiadamianie o których ma nastąpić, są określone w
\fIarg\fP, będącym maską bitową utworzoną jako suma logiczna (OR) zera lub
więcej spośród następujących bitów:
.P
.RS
.PD 0
.TP 
\fBDN_ACCESS\fP
Uzyskano dostęp do pliku (\fBread\fP(2), \fBpread\fP(2), \fBreadv\fP(2) i podobne)
.TP 
\fBDN_MODIFY\fP
Plik został zmodyfikowany (\fBwrite\fP(2), \fBpwrite\fP(2), \fBwritev\fP(2),
\fBtruncate\fP(2), \fBftruncate\fP(2) i podobne).
.TP 
\fBDN_CREATE\fP
Utworzono plik (\fBopen\fP(2), \fBcreat\fP(2), \fBmknod\fP(2), \fBmkdir\fP(2),
\fBlink\fP(2), \fBsymlink\fP(2), \fBrename\fP(2) w tym katalogu).
.TP 
\fBDN_DELETE\fP
Usunięto pliku (\fBunlink\fP(2), \fBrename\fP(2) do innego katalogu, \fBrmdir\fP(2)).
.TP 
\fBDN_RENAME\fP
Zmieniono nazwę w obrębie katalogu (\fBrename\fP(2)).
.TP 
\fBDN_ATTRIB\fP
Zmieniono atrybuty pliku (\fBchown\fP(2), \fBchmod\fP(2), \fButime\fP(2),
\fButimensat\fP(2) i podobne).
.PD
.RE
.IP
(Uzyskanie tych definicji wymaga zdefiniowania makra sprawdzania cech
\fB_GNU_SOURCE\fP przed włączeniem \fIjakichkolwiek\fP plików nagłówkowych).
.IP
Powiadomienia dotyczące katalogów są zazwyczaj jednorazowe, więc aplikacja
musi się ponownie zarejestrować, aby otrzymać dalsze
powiadomienia. Alternatywnie, jeśli w \fIarg\fP włączono \fBDN_MULTISHOT\fP, to
powiadomienia będą dokonywane aż do ich jawnego usunięcia.
.IP
.\" The following does seem a poor API-design choice...
Szereg wywołań podających \fBDN_MULTISHOT\fP kumuluje się, przy czym zdarzenia
w \fIarg\fP są dodawane logicznie do już monitorowanych. Aby wyłączyć
powiadamianie o jakichkolwiek zdarzeniach, należy w wywołaniu \fBF_NOTIFY\fP
podać \fIarg\fP równe 0.
.IP
Powiadamianie odbywa się poprzez dostarczenie sygnału. Domyślnym sygnałem
jest \fBSIGIO\fP, ale można go zmienić za pomocą operacji \fBF_SETSIG\fP w
\fBfcntl\fP() (proszę zauważyć, że \fBSIGIO\fP jest jednym z sygnałów
standardowych niepodlegających kolejkowaniu; przełączenie się na sygnały
czasu rzeczywistego oznacza, że do procesu może być kolejkowane wiele
zawiadomień). W tym drugim przypadku, funkcja obsługi sygnału otrzymuje jako
swój drugi argument strukturę \fIsiginfo_t\fP (gdy funkcja obsługi sygnału
została określona za pomocą \fBSA_SIGINFO\fP) a pole \fIsi_fd\fP tej struktury
zawiera deskryptor pliku, który spowodował powiadomienie (przydatne, gdy
utrzymywane są dzierżawy na wielu katalogach).
.IP
W szczególności, gdy używa się \fBDN_MULTISHOT\fP, do zawiadamiania powinien
być stosowany sygnał czasu rzeczywistego, tak aby można było kolejkować
wiele zmian.
.IP
\fBUWAGA:\fP Nowe aplikacje powinny korzystać z interfejsu \fIinotify\fP
(dostępnego od Linuksa 2.6.13), który zapewnia o wiele lepszy interfejs do
uzyskiwania powiadomień o zdarzeniach w systemie plików. Zob. \fBinotify\fP(7).
.SS "Zmiana pojemności potoku"
.TP 
\fBF_SETPIPE_SZ\fP (\fIint\fP; od Linuksa 2.6.35)
Zmienia pojemność potoku, do którego odnosi się \fIfd\fP na co najmniej \fIarg\fP
bajtów. Proces nieuprzywilejowany może dostosować pojemność potoku na
dowolną wartość pomiędzy systemowym rozmiarem strony i limitem zdefiniowanym
w \fI/proc/sys/fs/pipe\-max\-size\fP (zob. \fBproc\fP(5)). Próby ustawienia
pojemności potoku poniżej rozmiaru strony są po cichu zaokrąglane w górę, do
rozmiaru strony. Próby ustawienia przez proces nieuprzywilejowany rozmiaru
potoku powyżej limitu \fI/proc/sys/fs/pipe\-max\-size\fP prowadzą do błędu
\fBEPERM\fP; proces uprzywilejowany (\fBCAP_SYS_RESOURCE\fP) może przesłonić ten
limit.
.IP
Przy przydzielaniu bufora dla potoku, jądro może użyć pojemności większej
niż \fIarg\fP, gdy jest to wygodne ze względu na implementację (w bieżącej
implementacji, przydzielanie następuje do następnej wielokrotności będącej
potęgą dwójki, w stosunku do żądanego rozmiaru). Rzeczywista ustawiona
pojemność (w bajtach) jest zwracana jako wynik funkcji.
.IP
Próby ustawienia pojemności potoku poniżej aktualnie używanego rozmiaru
bufora, używanego do przechowywania jego danych, poskutkuje błędem \fBEBUSY\fP.
.IP
Proszę zauważyć, że ze względu na sposób, w jaki wykorzystywane są strony
bufora potoku, przy zapisywaniu danych do potoku, liczba możliwych do
zapisanych bajtów może być mniejsza, niż jego nominalny rozmiar, zależnie od
rozmiaru zapisów.
.TP 
\fBF_GETPIPE_SZ\fP (\fIvoid\fP; od Linuksa 2.6.35)
.\"
Zwraca (jako wynik funkcji) rozmiar potoku, do którego odnosi się \fIfd\fP.
.SS "Pieczętowanie pliku (ang. file sealing)"
Pieczęcie pliku ograniczają zestaw dozwolonych operacji na danym pliku. Od
momentu ustawienia pieczęci na pliku, określony zestaw operacji na tym pliku
zawiedzie z błędem \fBEPERM\fP. Taki plik określany jest jako zapieczętowany
(ang. sealed). Domyślny zestaw pieczęci zależy od typu pliku i systemu
plików. Przegląd pieczętowania plików, opis celowości i nieco przykładów
kodu zawarto w podręczniku \fBmemfd_create\fP(2).
.P
Obecnie, pieczęcie pliku można zastosować tylko na deskryptorze pliku
zwróconym przez \fBmemfd_create\fP(2) (jeśli użyto \fBMFD_ALLOW_SEALING\fP). W
innych systemach plików, wszystkie operacje \fBfcntl\fP() działające na
pieczęciach zwrócą \fBEINVAL\fP.
.P
Pieczęcie są właściwością i\-węzła. Z tego powodu, wszystkie opisy otwartego
pliku (OFD) odnoszące się do tego samego i\-węzła dzielą ten sam zestaw
pieczęci. Co więcej, pieczęci nigdy nie można usunąć, można je jedynie
dodawać.
.TP 
\fBF_ADD_SEALS\fP (\fIint\fP; od Linuksa 3.17)
Dodaje pieczęcie przekazane w argumencie \fIarg\fP, będącym maską bitową, do
zestawu pieczęci i\-węzła, do którego odnosi się deskryptor pliku
\fIfd\fP. Pieczęci nie można usunąć. Jeśli wywołanie się powiedzie, pieczęcie
są natychmiast stosowane przez jądro. Jeśli aktualny zestaw pieczęci
obejmuje \fBF_SEAL_SEAL\fP (zob. niżej), to wywołanie to zostanie odrzucone z
błędem \fBEPERM\fP. Dodanie pieczęci, która jest już ustawiona nie ma skutku, o
ile nie ustawiono \fBF_SEAL_SEAL\fP. Do umieszczenia pieczęci, deskryptor pliku
\fIfd\fP musi być zapisywalny.
.TP 
\fBF_GET_SEALS\fP (\fIvoid\fP; od Linuksa 3.17)
Zwraca (jako wynik funkcji) bieżący zestaw pieczęci i\-węzła, do którego
odnosi się \fIfd\fP. Jeśli nie ma ustawionych pieczęci, zwracane jest 0. Jeśli
plik nie obsługuje pieczętowania, zwracane jest \-1, a \fIerrno\fP jest
ustawiane na \fBEINVAL\fP.
.P
Dostępne są następujące pieczęcie:
.TP 
\fBF_SEAL_SEAL\fP
Jeśli ta pieczęć jest ustawiona, każde kolejne wywołanie \fBfcntl\fP() z
\fBF_ADD_SEALS\fP zawiedzie z błędem \fBEPERM\fP. Ta pieczęć zapobiega zatem
wszelkim modyfikacjom samego zestawu pieczęci. Jeśli początkowy zestaw
pieczęci pliku obejmuje \fBF_SEAL_SEAL\fP, to powoduje to efektywne ustawienie
stałego i zablokowanego zestawu pieczęci.
.TP 
\fBF_SEAL_SHRINK\fP
Jeśli ta pieczęć jest ustawiona, rozmiar przedmiotowego pliku nie może ulec
zmniejszeniu. Dotyczy to \fBopen\fP(2) ze znacznikiem \fBO_TRUNC\fP, jak również
\fBtruncate\fP(2) i \fBftruncate\fP(2). Jeśli spróbuje się zmniejszyć
zapieczętowany w ten sposób plik, wywołania te zawiodą z błędem
\fBEPERM\fP. Zwiększenie rozmiaru pliku jest wciąż możliwe.
.TP 
\fBF_SEAL_GROW\fP
Jeśli ta pieczęć jest ustawiona, rozmiar przedmiotowego pliku nie może ulec
zwiększeniu. Dotyczy to zapisu za pomocą \fBwrite\fP(2) poza koniec pliku,
\fBtruncate\fP(2), \fBftruncate\fP(2) oraz \fBfallocate\fP(2). Jeśli spróbuje się
zwiększyć zapieczętowany w ten sposób plik, wywołania te zawiodą z błędem
\fBEPERM\fP. Jeśli rozmiar pliku nie zmieni się lub ulegnie zmniejszeniu,
opisywane wywołania będą działać zgodnie z oczekiwaniami.
.TP 
\fBF_SEAL_WRITE\fP
.\" One or more other seals are typically used with F_SEAL_WRITE
.\" because, given a file with the F_SEAL_WRITE seal set, then,
.\" while it would no longer be possible to (say) write zeros into
.\" the last 100 bytes of a file, it would still be possible
.\" to (say) shrink the file by 100 bytes using ftruncate(), and
.\" then increase the file size by 100 bytes, which would have
.\" the effect of replacing the last hundred bytes by zeros.
.\"
Jeśli ta pieczęć jest ustawiona, nie można modyfikować zawartości
pliku. Proszę zwrócić uwagę, że zmniejszenie lub zwiększenie rozmiaru pliku
jest wciąż możliwe i dozwolone. Z tego względu, pieczęć ta jest zwykle
używana w połączeniu z innymi pieczęciami. Pieczęć wpływa na \fBwrite\fP(2) i
\fBfallocate\fP(2) (tylko w połączeniu ze znacznikiem
\fBFALLOC_FL_PUNCH_HOLE\fP). Jeśli pieczęć jest ustawiona, wywołania te zawiodą
z błędem \fBEPERM\fP. Co więcej, utworzenie nowego wspólnego, zapisywalnego
przypisania pamięci za pomocą \fBmmap\fP(2) również zawiedzie z błędem
\fBEPERM\fP.
.IP
Użycie operacji \fBF_ADD_SEALS\fP do ustawienia pieczęci \fBF_SEAL_WRITE\fP
zawiedzie z błędem \fBEBUSY\fP, jeśli istnieją zapisywalne, wspólne przypisania
pamięci. Przed dodaniem tej pieczęci konieczne jest ich
odmapowanie. Ponadto, jeśli wobec pliku istnieją jakieś oczekujące
asynchroniczne operacje wejścia/wyjścia (\fBio_submit\fP(2)), to wszystkie
pozostałe zapisy zostaną odrzucone.
.TP 
\fBF_SEAL_FUTURE_WRITE\fP (od Linuksa 5.1)
Skutek zastosowania tej pieczęci jest podobny do \fBF_SEAL_WRITE\fP, lecz
zawartość pliku można wciąż zmodyfikować za pomocą wspólnych, zapisywalnych
przypisań pamięci, które utworzono przed ustawieniem pieczęci. Próba
utworzenia nowego zapisywalnego przypisania na pliku za pomocą \fBmmap\fP(2),
zawiedzie z błędem \fBEPERM\fP. Podobnie, próba zapisu do pliku za pomocą
\fBwrite\fP(2) również zawiedzie z błędem \fBEPERM\fP.
.IP
.\"
Korzystając z tej pieczęci, proces może utworzyć bufor pamięci, który będzie
mógł wciąż modyfikować, dzieląc go jednocześnie na zasadzie \[Bq]tylko do
odczytu\[rq] z innymi procesami.
.SS "Wskazówki odczytu/zapisu pliku"
Do poinformowania jądra o oczekiwanym, względnym czasie istnienia zapisów do
danego i\-węzła lub za pomocą opisu otwartego pliku (OFD; więcej informacji o
opisach otwartego pliku w podręczniku \fBopen\fP(2)) można użyć wskazówek czasu
istnienia zapisu. W tym kontekście, pojęcie \[Bq]czas istnienia zapisu\[rq]
oznacza oczekiwany czas, jaki dane będą istniały na nośniku, przed ich
nadpisaniem lub usunięciem.
.P
Aplikacja może korzystać z różnych, podanych niżej, wartości wskazówek, aby
podzielić zapisy na różne klasy zapisów, dzięki czemu wielu użytkowników lub
aplikacji działających na stacji z pojedynczym nośnikiem może zbierać swoje
wejścia/wyjścia w spójny sposób. Jednak znaczniki te nie udostępniają
żadnego funkcjonalnego zachowania, a różne klasy wejścia/wyjścia mogą używać
wskazówek o czasie trwania zapisu w arbitralny sposób dopóki tylko wskazówki
są stosowane konsekwentnie.
.P
Do deskryptora \fIfd\fP można zastosować następujące operacje:
.TP 
\fBF_GET_RW_HINT\fP (\fIuint64_t *\fP; od Linuksa 4.13)
Zwraca wartość wskazówki odczytu/zapisu powiązanej z i\-węzłem, do którego
odnosi się \fIfd\fP.
.TP 
\fBF_SET_RW_HINT\fP (\fIuint64_t *\fP; od Linuksa 4.13)
Ustawia wartość wskazówki odczytu/zapisu powiązanej z i\-węzłem, do którego
odnosi się \fIfd\fP. Wskazówka ta będzie istniała do momentu jej jawnej
modyfikacji lub do momentu odmontowania przedmiotowego systemu plików.
.TP 
\fBF_GET_FILE_RW_HINT\fP (\fIuint64_t *\fP; od Linuksa 4.13)
Zwraca wartość wskazówki odczytu/zapisu powiązanej z opisem otwartego pliku
(OFD), do którego odnosi się \fIfd\fP.
.TP 
\fBF_SET_FILE_RW_HINT\fP (\fIuint64_t *\fP; od Linuksa 4.13)
Ustawia wartość wskazówki odczytu/zapisu powiązanej z opisem otwartego pliku
(OFD), do którego odnosi się \fIfd\fP.
.P
Jeśli opisowi otwartego pliku nie przypisano wskazówki odczytu/zapisu,
powinien on użyć wartości przypisanej i\-węzłowi, jeśli taka istnieje.
.P
Od Linuksa 4.13 prawidłowe są następujące wskazówki odczytu/zapisu:
.TP 
\fBRWH_WRITE_LIFE_NOT_SET\fP
Nie ustawiono żadnej wskazówki. Jest to wartość domyślna.
.TP 
\fBRWH_WRITE_LIFE_NONE\fP
Nie ustawiono wskazówki zapisu z danym plikiem lub i\-węzłem.
.TP 
\fBRWH_WRITE_LIFE_SHORT\fP
Oczekuje się, że dane zapisane do tego i\-węzła lub za pomocą tego opisu
otwartego pliku, będą istniały krótko.
.TP 
\fBRWH_WRITE_LIFE_MEDIUM\fP
Oczekuje się, że dane zapisane do tego i\-węzła lub za pomocą tego opisu
otwartego pliku, będą istniały dłużej, niż dane zapisane ze wskazówką
\fBRWH_WRITE_LIFE_SHORT\fP.
.TP 
\fBRWH_WRITE_LIFE_LONG\fP
Oczekuje się, że dane zapisane do tego i\-węzła lub za pomocą tego opisu
otwartego pliku, będą istniały dłużej, niż dane zapisane ze wskazówką
\fBRWH_WRITE_LIFE_MEDIUM\fP.
.TP 
\fBRWH_WRITE_LIFE_EXTREME\fP
Oczekuje się, że dane zapisane do tego i\-węzła lub za pomocą tego opisu
otwartego pliku, będą istniały dłużej, niż dane zapisane ze wskazówką
\fBRWH_WRITE_LIFE_LONG\fP.
.P
Wszystkie wskazówki dotyczące zapisu są jedynie relatywne względem siebie i
nie należy przypisywać im bezwzględnego znaczenia.
.SH "WARTOŚĆ ZWRACANA"
Wartość zwracana po pomyślnym zakończeniu funkcji zależy od operacji:
.TP 
\fBF_DUPFD\fP
Nowy deskryptor pliku.
.TP 
\fBF_GETFD\fP
Wartość znaczników deskryptora pliku.
.TP 
\fBF_GETFL\fP
Wartość znaczników stanu pliku
.TP 
\fBF_GETLEASE\fP
Typ dzierżawy ustanowionej na deskryptorze pliku.
.TP 
\fBF_GETOWN\fP
Wartość właściciela deskryptora pliku.
.TP 
\fBF_GETSIG\fP
Wartość sygnału wysłanego, gdy odczyt lub zapis staną się możliwe, lub zero,
dla tradycyjnego zachowania \fBSIGIO\fP.
.TP 
\fBF_GETPIPE_SZ\fP
.TQ
\fBF_SETPIPE_SZ\fP
Pojemność potoku.
.TP 
\fBF_GET_SEALS\fP
Mapa bitowa identyfikująca pieczęcie, które ustawiono dla i\-węzła, do
którego odnosi się \fIfd\fP.
.TP 
Wszystkie pozostałe operacje
Zero.
.P
W razie wystąpienia błędu zwracane jest \-1 i ustawiane \fIerrno\fP wskazując
błąd.
.SH BŁĘDY
.TP 
\fBEACCES\fP lub \fBEAGAIN\fP
Operacja uniemożliwiona przez blokady utrzymywane przez inne procesy.
.TP 
\fBEAGAIN\fP
Operacja jest zabroniona, gdyż plik został odwzorowany w pamięci przez inny
proces.
.TP 
\fBEBADF\fP
\fIfd\fP nie jest deskryptorem otwartego pliku.
.TP 
\fBEBADF\fP
\fIop\fP wynosi \fBF_SETLK\fP lub \fBF_SETLKW\fP a tryb otwarcia deskryptora pliku
nie odpowiada rodzajowi żądanej blokady.
.TP 
\fBEBUSY\fP
\fIop\fP wynosi \fBF_SETPIPE_SZ\fP, a nowa pojemność potoku określona w \fIarg\fP
jest mniejsza, niż przestrzeń bufora aktualnie zajęta do przechowywania
danych w potoku.
.TP 
\fBEBUSY\fP
\fIop\fP wynosi \fBF_ADD_SEALS\fP, \fIarg\fP zawiera \fBF_SEAL_WRITE\fP i istnieje
zapisywalne, dzielone przypisanie pliku, do którego odnosi się \fIfd\fP.
.TP 
\fBEDEADLK\fP
Stwierdzono, że podana operacja \fBF_SETLKW\fP spowodowałoby zakleszczenie
blokad.
.TP 
\fBEFAULT\fP
\fIlock\fP znajduje się poza dostępną dla użytkownika przestrzenią adresową.
.TP 
\fBEINTR\fP
\fIop\fP wynosi \fBF_SETLKW\fP lub \fBF_OFD_SETLKW\fP i operacja została przerwana
sygnałem; zob. \fBsignal\fP(7).
.TP 
\fBEINTR\fP
\fIop\fP wynosi \fBF_GETLK\fP, \fBF_SETLK\fP, \fBF_OFD_GETLK\fP lub \fBF_OFD_SETLK\fP, a
operacja została przerwana przez sygnał, zanim blokada została sprawdzona
lub ustawiona. Najbardziej prawdopodobne podczas blokowania zdalnego pliku
(np. blokowanie przez NFS), ale czasami zdarza się lokalnie.
.TP 
\fBEINVAL\fP
Wartość podana w \fIop\fP nie jest rozpoznawana przez to jądro.
.TP 
\fBEINVAL\fP
\fIop\fP wynosi \fBF_ADD_SEALS\fP, a \fIarg\fP obejmuje nierozpoznany bit pieczęci.
.TP 
\fBEINVAL\fP
\fIop\fP wynosi \fBF_ADD_SEALS\fP lub \fBF_GET_SEALS\fP, a system plików zawierający
i\-węzeł, do którego odnosi się \fIfd\fP, nie obsługuje pieczętowania.
.TP 
\fBEINVAL\fP
\fIop\fP wynosi \fBF_DUPFD\fP, a \fIarg\fP jest ujemny lub większy od maksymalnej
dozwolonej wartości (więcej informacji w opisie \fBRLIMIT_NOFILE\fP w
podręczniku \fBgetrlimit\fP(2)).
.TP 
\fBEINVAL\fP
\fIop\fP wynosi \fBF_SETSIG\fP, a \fIarg\fP nie jest dozwolonym numerem sygnału.
.TP 
\fBEINVAL\fP
\fIop\fP wynosi \fBF_OFD_SETLK\fP, \fBF_OFD_SETLKW\fP lub \fBF_OFD_GETLK\fP, a \fIl_pid\fP
nie podano jako zero.
.TP 
\fBEMFILE\fP
\fIop\fP wynosi \fBF_DUPFD\fP, a osiągnięto już maksymalną liczbę otwartych
deskryptorów plików na proces.
.TP 
\fBENOLCK\fP
Zbyt wiele otwartych blokad segmentowych, tablica blokad jest pełna lub
zawiódł protokół blokowania zdalnego (np. dla blokad przez NFS).
.TP 
\fBENOTDIR\fP
W \fIop\fP podano \fBF_NOTIFY\fP, lecz \fIfd\fP nie odnosi się do katalogu.
.TP 
\fBEPERM\fP
\fIop\fP wynosi \fBF_SETPIPE_SZ\fP i osiągnięto miękki lub sztywny limit potoku;
zob. \fBpipe\fP(7).
.TP 
\fBEPERM\fP
Próbowano wyzerować znacznik \fBO_APPEND\fP na pliku posiadającym ustawiony
atrybut \[Bq]append\-only\[rq].
.TP 
\fBEPERM\fP
\fIop\fP wynosiło \fBF_ADD_SEALS\fP, lecz \fIfd\fP nie był otwarty do zapisu albo
bieżący zestaw pieczęci już obejmuje \fBF_SEAL_SEAL\fP.
.SH STANDARDY
POSIX.1\-2008.
.P
.\" .P
.\" SVr4 documents additional EIO, ENOLINK and EOVERFLOW error conditions.
\fBF_GETOWN_EX\fP, \fBF_SETOWN_EX\fP, \fBF_SETPIPE_SZ\fP, \fBF_GETPIPE_SZ\fP,
\fBF_GETSIG\fP, \fBF_SETSIG\fP, \fBF_NOTIFY\fP, \fBF_GETLEASE\fP i \fBF_SETLEASE\fP są
typowo linuksowe (należy zdefiniować makro \fB_GNU_SOURCE\fP aby pozyskać te
definicje).
.P
\fBF_OFD_SETLK\fP, \fBF_OFD_SETLKW\fP i \fBF_OFD_GETLK\fP są typowo linuksowe (i
konieczne jest zdefiniowanie \fB_GNU_SOURCE\fP do pozyskania ich definicji),
lecz trwają prace nad włączeniem ich do następnej wersji POSIX.1.
.P
.\" FIXME . Once glibc adds support, add a note about FTM requirements
\fBF_ADD_SEALS\fP i \fBF_GET_SEALS\fP są typowo linuksowe.
.SH HISTORIA
SVr4, 4.3BSD, POSIX.1\-2001.
.P
Jedynie operacje \fBF_DUPFD\fP, \fBF_GETFD\fP, \fBF_SETFD\fP, \fBF_GETFL\fP, \fBF_SETFL\fP,
\fBF_GETLK\fP, \fBF_SETLK\fP i \fBF_SETLKW\fP są określone w POSIX.1\-2001.
.P
.\" .BR _BSD_SOURCE ,
.\" or
\fBF_GETOWN\fP i \fBF_SETOWN\fP są określone w POSIX.1\-2001 (do pozyskania ich
definicji konieczne jest zdefiniowanie \fB_XOPEN_SOURCE\fP z wartością 500 lub
większą albo \fB_POSIX_C_SOURCE\fP z wartością 200809L lub większą).
.P
\fBF_DUPFD_CLOEXEC\fP jest określone w POSIX.1\-2008 (do pozyskania jego
definicji konieczne jest zdefiniowanie \fB_POSIX_C_SOURCE\fP z wartością
200809L lub większą albo \fB_XOPEN_SOURCE\fP z wartością 700 lub większą).
.SH UWAGI
.\"
Błędy zwracane przez \fBdup2\fP(2) są inne niż zwracane przez \fBF_DUPFD\fP.
.SS "Blokowanie plików"
.\"
Pierwotne linuksowe wywołanie systemowego \fBfcntl\fP() nie było zaprojektowane
do obsługi dużych przesunięć plików (w strukturze \fIflock\fP). W konsekwencji,
Linux 2.4 dodał wywołanie systemowe \fBfcntl64\fP(). Nowsze wywołanie systemowe
korzysta z odmiennej struktury do blokowania plików, \fIflock64\fP i
odpowiadających operacji, \fBF_GETLK64\fP, \fBF_SETLK64\fP i \fBF_SETLKW64\fP. Detale
te mogą być jednak zignorowane przez aplikacje używające glibc, ponieważ jej
funkcja opakowująca \fBfcntl\fP() obsługuje nowsze wywołanie systemowe, gdy
tylko jest dostępne, w sposób przezroczysty.
.SS "Blokady rekordów"
Od Linuksa 2.0, nie ma oddziaływania pomiędzy typami blokad zakładanych
przez \fBflock\fP(2) i przez \fBfcntl\fP().
.P
.\" e.g., Solaris 8 documents this field in fcntl(2), and Irix 6.5
.\" documents it in fcntl(5).  mtk, May 2007
.\" Also, FreeBSD documents it (Apr 2014).
W niektórych systemach struktura \fIstruct flock\fP zawiera dodatkowe pola,
takie jak np. \fIl_sysid\fP (do identyfikacji komputera, na którym utrzymywana
jest blokada). Oczywiście, samo \fIl_pid\fP jest mało przydatne, gdy proces
utrzymujący blokadę może działać na innym komputerze; w Linuksie, choć pole
to jest obecne na niektórych architekturach (np. MIPS32), to jednak nie jest
używane.
.P
Pierwotne linuksowe wywołanie systemowego \fBfcntl\fP() nie było zaprojektowane
do obsługi dużych przesunięć plików (w strukturze \fIflock\fP). W konsekwencji,
Linux 2.4 dodał wywołanie systemowe \fBfcntl64\fP(). Nowsze wywołanie systemowe
korzysta z odmiennej struktury do blokowania plików, \fIflock64\fP i
odpowiadających operacji, \fBF_GETLK64\fP, \fBF_SETLK64\fP i \fBF_SETLKW64\fP. Detale
te mogą być jednak zignorowane przez aplikacje używające glibc, ponieważ jej
funkcja opakowująca \fBfcntl\fP() obsługuje nowsze wywołanie systemowe, gdy
tylko jest dostępne, w sposób przezroczysty.
.SS "Blokowanie rekordów i NFS"
.\"
.\" Neil Brown: With NFSv3 the failure mode is the reverse.  If
.\"     the server loses contact with a client then any lock stays in place
.\"     indefinitely ("why can't I read my mail"... I remember it well).
.\"
.\"
.\" Jeff Layton:
.\"     Note that this is not a firm timeout. The server runs a job
.\"     periodically to clean out expired stateful objects, and it's likely
.\"     that there is some time (maybe even up to another whole lease period)
.\"     between when the timeout expires and the job actually runs. If the
.\"     client gets a RENEW in there within that window, its lease will be
.\"     renewed and its state preserved.
.\"
Przed Linuksem 3.12, jeśli klient NFSv4 utraci kontakt z serwerem na pewien
czas (zdefiniowany jako ponad 90 sekund bez żadnej komunikacji), to może
utracić i odzyskać blokadę bez uświadamiania sobie tego faktu (czas, po
którym przyjmuje się utratę połączenia jest znany jako czas dzierżawy NFSv4
(leasetime); na serwerze NFS można go sprawdzić w pliku
\fI/proc/fs/nfsd/nfsv4leasetime\fP, który podaje go w sekundach; domyślną
wartością w pliku jest 90). Ten scenariusz grozi uszkodzeniem danych,
ponieważ inny proces mógł w międzyczasie posiąść blokadę i dokonać operacji
wejścia/wyjścia na pliku.
.P
.\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d
.\" commit f6de7a39c181dfb8a2c534661a53c73afb3081cd
Od Linuksa 3.12, jeśli klient NFSv4 utraci połączenie z serwerem, każda
operacja wejścia/wyjścia na pliku, przez proces który \[Bq]sądzi\[rq], że
utrzymuje blokadę zawiedzie, dopóki ten proces nie zamknie i nie otworzy
pliku ponownie. Można ustawić parametr jądra \fInfs.recover_lost_locks\fP na 1,
aby powrócić do zachowania sprzed wersji 3.12, gdy klient próbuje odzyskać
zagubione blokady po odzyskaniu połączenia z serwerem. Ze względu na
towarzyszące temu ryzyko uszkodzenia danych, domyślnie parametr ten wynosi 0
(jest wyłączony).
.SH USTERKI
.SS F_SETFL
.\" FIXME . According to POSIX.1-2001, O_SYNC should also be modifiable
.\" via fcntl(2), but currently Linux does not permit this
.\" See http://bugzilla.kernel.org/show_bug.cgi?id=5994
Nie da się użyć \fBF_SETFL\fP do zmiany statusu znaczników \fBO_DSYNC\fP i
\fBO_SYNC\fP. Takie próby zostaną po cichu zignorowane.
.SS F_GETOWN
.\" glibc source: sysdeps/unix/sysv/linux/i386/sysdep.h
.\" mtk, Dec 04: some limited testing on alpha and ia64 seems to
.\" indicate that ANY negative PGID value will cause F_GETOWN
.\" to misinterpret the return as an error. Some other architectures
.\" seem to have the same range check as i386.
Ograniczenie konwencji linuksowego wywołania systemowego na niektórych
architekturach (przede wszystkim i386) oznacza, że jeśli (ujemny)
identyfikator grupy procesu mający być zwrócony przez \fBF_GETOWN\fP znajduje
się w przedziale od \-1 do \-4095, to zwracana wartość jest przez glibc
nieprawidłowo interpretowana jako błąd w wywołaniu systemowym; to jest
zwrócona przez \fBfcntl\fP() wartość będzie wynosiła \-1, a \fIerrno\fP będzie
zawierać (dodatni) identyfikator grupy procesu. Typowo linuksowa operacja
\fBF_GETOWN_EX\fP unika tego problemu. Od glibc 2.11, glibc czyni problem jądra
\fBF_GETOWN\fP niewidzialnym, przez zaimplementowanie \fBF_GETOWN\fP za pomocą
\fBF_GETOWN_EX\fP.
.SS F_SETOWN
.\"
W Linuksie 2.4 i wcześniejszych istnieje błąd, który może się ujawnić, gdy
proces nieuprzywilejowany używa \fBF_SETOWN\fP do podania właściciela
deskryptora pliku gniazda, będące procesem (grupą) inną niż wywołujący. W
tym przypadku \fBfcntl\fP() może zwrócić \-1 z \fIerrno\fP ustawionym na \fBEPERM\fP
nawet wówczas, gdy właściciel procesu (grupy) był tym, do którego wywołujący
ma prawo wysyłania sygnałów. Pomimo zwracania błędu, własność deskryptora
pliku jest ustawiana, a sygnały będą wysyłane do właściciela.
.SS "Wykrywanie zakleszczeń"
.\"
Algorytm wykrywania zakleszczeń używany przez jądro przy przetwarzaniu żądań
\fBF_SETLKW\fP może skutkować wykryciami zarówno fałszywie negatywnymi
(niewykryciem zakleszczeń, pozostawiając zestaw zakleszczonych procesów
stale zablokowanymi), jak i fałszywie pozytywnymi (błąd \fBEDEADLK\fP, gdy
zakleszczenie nie występuje). Przykładowo, jądro ogranicza głębokość
poszukiwania zależności blokad do 10 kroków co oznacza, że łańcuch kolistych
zakleszczeń większy od tego rozmiaru nie zostanie wykryty. Dodatkowo, jądro
może nieprawidłowo wskazywać zakleszczenie, gdy dwa lub więcej procesów
utworzonych za pomocą znacznika   \fBCLONE_FILES\fP z \fBclone\fP(2), wyglądają
(dla jądra) na będące w konflikcie.
.SS "Blokowanie obowiązujące (przymusowe)"
.\" http://marc.info/?l=linux-kernel&m=119013491707153&w=2
.\"
.\" Reconfirmed by Jeff Layton
.\"     From: Jeff Layton <jlayton <at> redhat.com>
.\"     Subject: Re: Status of fcntl() mandatory locking
.\"     Newsgroups: gmane.linux.file-systems
.\"     Date: 2014-04-28 10:07:57 GMT
.\"     http://thread.gmane.org/gmane.linux.file-systems/84481/focus=84518
Linuksowa implementacja blokowania obowiązującego (przymusowego) jest
podatna na sytuację wyścigu, co czyni ją nierzetelną: wywołanie \fBwrite\fP(2),
które nachodzi na blokadę może zmodyfikować dane po uzyskaniu blokady,
wywołanie \fBread\fP(2) które nachodzi na blokadę może wykryć zmianę danych,
dokonaną jedynie po uzyskaniu blokady zapisu. Podobny wyścig istnieje
pomiędzy blokadami obowiązującymi a \fBmmap\fP(2). Z tego powodu nie należy
polegać na blokowaniu obowiązującym.
.SH "ZOBACZ TAKŻE"
\fBdup2\fP(2), \fBflock\fP(2), \fBopen\fP(2), \fBsocket\fP(2), \fBlockf\fP(3),
\fBcapabilities\fP(7), \fBfeature_test_macros\fP(7), \fBlslocks\fP(8)
.P
\fIlocks.txt\fP, \fImandatory\-locking.txt\fP i \fIdnotify.txt\fP w katalogu
\fIDocumentation/filesystems/\fP źródeł jądra Linux (w starszych jądrach pliki
te znajdują się bezpośrednio w katalogu \fIDocumentation/\fP, a plik
\fImandatory\-locking.txt\fP ma nazwę \fImandatory.txt\fP)
.PP
.SH TŁUMACZENIE
Autorami polskiego tłumaczenia niniejszej strony podręcznika są:
Przemek Borys <pborys@dione.ids.pl>,
Andrzej Krzysztofowicz <ankry@green.mf.pg.gda.pl>
i
Michał Kułach <michal.kulach@gmail.com>
.
.PP
Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach
licencji można uzyskać zapoznając się z
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License w wersji 3
.UE
lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI.
.PP
Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy
dyskusyjnej
.MT manpages-pl-list@lists.sourceforge.net
.ME .
