.\" -*- 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.8" .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 .