Provided by: manpages-de-dev_2.5-1_all 
BEZEICHNUNG
fcntl - Dateideskriptoren manipulieren
ÜBERSICHT
#include <unistd.h>
#include <fcntl.h>
int fcntl(int fd, int cmd, … /* arg */ );
BESCHREIBUNG
fcntl() führt eine der unten beschriebenen Aktionen auf dem offenen Dateideskriptor fd
aus. Die Aktion wird durch cmd festgelegt.
fcntl() kann ein optionales drittes Argument akzeptieren. Ob dieses Argument notwendig
ist, ergibt sich durch cmd. Der benötigte Argumenttyp wird nach jedem cmd-Namen in
Klammern angedeutet (in den meisten Fällen ist der benötigte Typ int und der Argumenttyp
wird mit dem Namen arg identifiziert). Falls das Argument nicht notwendig ist, wird void
angegeben.
Bestimmte der unten aufgeführten Aktionen werden nur seit einer bestimmten
Linux-Kernelversion unterstützt. Die bevorzugte Methode, um herauszufinden, ob der
Gastkernel eine bestimmte Aktion unterstützt, ist der Aufruf von fcntl() mit dem
gewünschten Wert von cmd und dem anschließenden Test, ob der Aufruf mit EINVAL fehlschlug,
wodurch angezeigt wird, dass der Kernel diesen Wert nicht unterstützt.
Duplizieren eines Dateideskriptors
F_DUPFD (int)
verdoppelt den Dateideskriptor fd unter Verwendung des Dateideskriptors mit der
kleinsten Nummer, die identisch zu oder größer als arg ist. Dies unterscheidet sich
von dup2(2), das exakt den angegebenen Dateideskriptor verwendet.
Bei Erfolg wird der neue Dateideskriptor zurückgegeben.
Lesen Sie dup(2) für weitere Details.
F_DUPFD_CLOEXEC (int; seit Linux 2.6.24)
Wie für F_DUPFD, setzt aber zusätzlich den Schalter »close-on-exec« für den
duplizierten Dateideskriptor. Die Angabe dieses Schalters ermöglicht es einem
Programm, eine zusätzliche fcntl()-F_SETFD-Aktion zu vermeiden, um den Schalter
FD_CLOEXEC zu setzen. Für eine Erläuterung, warum dieser Schalter nützlich ist,
lesen Sie die Beschreibung von O_CLOEXEC in open(2).
Datei-Deskriptor-Schalter
Die folgenden Befehle verändern die einem Dateideskriptor zugeordneten Schalter. Derzeit
ist nur ein solcher Schalter definiert: FD_CLOEXEC, der »close-on-exec«-Schalter. Falls
das FD_CLOEXEC-Bit gesetzt ist, wird der Dateideskriptor automatisch bei einem
erfolgreichen execve(2) geschlossen. (Falls der execve(2) fehlschlägt, bleibt der
Dateideskriptor offen.) Falls das Bit FD_CLOEXEC nicht gesetzt ist, wird der
Dateideskriptor über ein execve(2) hinweg offen bleiben.
F_GETFD (void)
Liefert (als Ergebnis der Funktion) die Dateideskriptorschalter; arg wird
ignoriert.
F_SETFD (int)
Setzt den Dateideskriptorschalter auf den durch arg angegebenenen Wert.
In Programmen mit mehreren Threads ist die Verwendung von fcntl() F_SETFD, um den Schalter
»close-on-exec« zum gleichen Zeitpunkt zu setzen, zu dem ein anderer Thread ein fork(2)
mit einem execve(2) ausführt, anfällig für einen Ressourcenwettlauf, der
unbeabsichtigterweise den Dateideskriptor an das Programm, das im Kindprozess läuft,
durchsickern lässt. Siehe die Diskussion des Schalters O_CLOEXEC in open(2) für Details
und wie dem Problem abgeholfen werden kann.
Dateistatusschalter
Jede offene Dateideskription hat bestimmte zugeordnete Statusschalter, die durch open(2)
initialisiert und möglicherweise durch fcntl() verändert werden. Duplizierte
Dateideskriptoren (mit dup(2), fcntl(F_DUPFD), fork(2) usw. erstellte) beziehen sich auf
die gleiche offene Dateideskription und teilen sich daher die gleichen
Dateistatusschalter.
Die Dateistatusschalter und deren Bedeutung sind in open(2) beschrieben.
F_GETFL (void)
Liefert (als Ergebnis der Funktion) den Dateizugriffsmodus und die
Dateistatusschalter; arg wird ignoriert.
F_SETFL (int)
Setzt die Dateistatusschalter auf den durch arg festgelegten Wert.
Dateizugriffsmodus (O_RDONLY, O_WRONLY, O_RDWR) und Dateierzeugungsschalter (d.h.
O_CREAT, O_EXCL, O_NOCTTY, O_TRUNC) werden in arg ignoriert. Unter Linux kann
dieser Befehl nur die Schalter O_APPEND, O_ASYNC, O_DIRECT, O_NOATIME und
O_NONBLOCK ändern. Es ist nicht möglich, die Schalter O_DSYNC und O_SYNC zu ändern,
siehe FEHLER weiter unten.
Empfohlene Datensatzsperren
Linux implementiert traditionelle (»Prozess-orientierte«) UNIX-Datensatz-Sperren, wie
durch POSIX standardisiert. Für eine Linux-spezifische Alternative mit besserer Semantik
lesen Sie die Diskussion über offene Dateideskriptions-Sperren unten.
F_SETLK, F_SETLKW und F_GETLK werden dazu verwandt, Datensatzsperren (auch bekannt als
Byte-Bereichs-, Dateisegment- oder Dateiregionsperren) zu erlangen, abzugeben oder auf
deren Existenz zu prüfen. Das dritte Argument, lock, ist ein Zeiger auf eine Struktur, die
mindestens die folgende Felder (in einer nicht festgelegten Reihenfolge) enthält:
struct flock {
…
short l_type; /* Art der Sperre: F_RDLCK,
F_WRLCK, F_UNLCK */
short l_whence; /* Wie l_start interpretiert wird:
SEEK_SET, SEEK_CUR, SEEK_END */
off_t l_start; /* Anfangsversatz für Sperre */
off_t l_len; /* Anzahl von zu sperrenden Bytes */
pid_t l_pid; /* PID des Prozesses, der unsere Sperre blockiert
(gesetzt durch F_GETLK und F_OFD_GETLK) */
…
};
Die Felder l_whence, l_start und l_len dieser Struktur legen den Bereich der Bytes, die
gesperrt werden sollen, fest. Bytes hinter dem Ende der Datei können gesperrt sein, aber
Bytes vor dem Anfang der Datei sind es nicht.
l_start ist der Startversatz für die Sperre und wird relativ zu einem der folgenden
interpretiert: Dem Anfang der Datei (falls l_whence SEEK_SET ist) oder dem Ende der Datei
(falls l_whence SEEK_END ist). In den abschließenden zwei Fällen kann l_start eine
negative Zahl sein, vorausgesetzt, der Versatz liegt nicht vor dem Anfang der Datei.
l_len legt die Anzahl der zu sperrenden Bytes fest. Falls l_len positiv ist, wird der zu
sperrende Bereich die Bytes l_start bis einschließlich l_start+l_len-1 umfassen. Die
Angabe von 0 für l_len hat eine besondere Bedeutung: Alle Bytes beginnend bei l_whence und
l_start bis zum Ende der Datei sperren, unabhängig davon, wie groß die Datei anwächst.
POSIX.1-2001 erlaubt (verlangt es aber nicht), dass eine Implementierung einen negativen
Wert für l_len unterstützt. Falls l_len negativ ist, deckt das durch lock beschriebene
Intervall die Bytes l_start+l_len bis zu einschließlich l_start-1 ab. Dies wird durch
Linux seit Kernelversion 2.4.21 and 2.5.49 unterstützt.
Das Feld l_type kann dazu verwandt werden, eine Lese- (F_RDLCK) oder Schreibsperre
(F_WRLCK) auf eine Datei zu setzen. Eine beliebige Anzahl an Prozessen kann eine
Lesesperre auf eine Dateiregion halten (gemeinsame Sperre), aber nur ein Prozess kann eine
Schreibsperre (exklusive Sperre) halten. Eine exklusive Sperre sperrt alle anderen Sperren
aus, sowohl exklusive als auch gemeinsame. Ein einzelner Prozess kann nur eine Art von
Sperre auf eine Dateiregion halten. Falls eine neue Sperre auf eine bereits gesperrte
Region angewandt wird, wird die existierende Sperre in den Typ der neuen Sperre
umgewandelt. (Solche Umwandlungen können das Teilen, Verkleinern, Vereinigen mit
bestehenden Sperren beinhalten, falls der durch die neue Sperre festgelegte Byte-Bereiche
nicht genau mit dem Bereich der bereits existierenden Sperre zusammenfällt.)
F_SETLK (struct flock *)
Erlangt (wenn l_type F_RDLCK oder F_WRLCK ist) oder gibt eine Sperre (wenn l_type
F_UNLCK ist) für die durch die Felder l_whence, l_start und l_len von lock
festgelegten Bytes ab. Falls durch einen anderen Prozess eine im Konflikt stehende
Sperre gehalten wird, liefert dieser Aufruf -1 zurück und setzt errno auf EACCES
oder EAGAIN. (Der in diesem Fall zurückgelieferte Fehler unterscheidet sich
zwischen Implementierungen, daher verlangt POSIX, dass portable Anwendungen auf
beide Fehler prüfen.)
F_SETLKW (struct flock *)
Wie für F_SETLK, aber bei Konflikten um eine Sperre auf die Datei wird auf die
Freigabe der Sperre gewartet. Falls während des Wartens ein Signal abgefangen wird,
dann wird der Aufruf unterbrochen und (nachdem der Signalbearbeiter zurückgekehrt
ist) sofort zurückgekehrt (mit dem Rückgabewert -1 und errno auf EINTR gesetzt;
siehe signal(7)).
F_GETLK (struct flock *)
Als Eingabe zu diesem Aufruf beschreibt lock eine Sperre, die auf diese Datei
angewandt werden soll. Falls die Sperre angewandt werden könnte, setzt fcntl()
diese nicht wirklich, sondern liefert F_UNLCK in dem Feld l_type von lock und lässt
die anderen Felder dieser Struktur unverändert.
Falls eine oder mehrere inkompatible Sperren das Setzen dieser Sperre verhinderten,
dann liefert fcntl() Details über eine dieser Sperren in den Feldern l_type,
l_whence, l_start und l_len von lock zurück. Falls die im Konflikt stehende Sperre
eine traditionelle (Prozess-orientierte) Datensatzsperre ist, dann wird das Feld
l_pid auf die PID des Prozesses gesetzt, der die Sperre hält. Falls die in Konflikt
stehende Sperre eine offene Dateideskriptionssperre ist, dann wird l_pid auf -1
gesetzt. Beachten Sie, dass die zurückgelieferte Information zum Zeitpunkt der
Analyse durch den Aufrufenden bereits veraltet sein kann.
Um eine Lesesperre zu setzen, muss fd zum Lesen offen sein. Um eine Schreibsperre zu
setzen, muss fd zum Schreiben offen sein. Um beide Typen setzen zu können, öffnen Sie eine
Datei lese- und schreibbar.
Wenn Sperren mit F_SETLKW gesetzt werden, erkennt der Kernel Verklemmungen, bei denen zwei
oder mehr Prozesse ihre Sperr-Anfragen gegenseitig durch Sperren, die von anderen
Prozessen gehalten werden, blockieren. Nehmen Sie beispielsweise an, Prozess A hält eine
Schreibsperre auf Byte 100 einer Datei und Prozess B hält eine Schreibsperre auf Byte 200.
Falls jeder Prozess dann versucht, mit F_SETLKW die vom anderen Prozess bereits gesperrten
Bytes zu sperren, würden ohne Erkennung von Verklemmungen beide Prozesse unbegrenzt
blockiert bleiben. Wenn der Kernel solche Verklemmungen erkennt, sorgt er dafür, dass eine
der blockierenden Sperranfragen sofort mit dem Fehler EDEADLK fehlschlägt. Eine Anwendung,
die auf einen solchen Fehler trifft, sollte einige ihrer Sperren freigeben, um anderen
Anwendungen das Fortfahren zu erlauben, bevor sie erneut versucht, die von ihr benötigten
Sperren zu erlangen. Zirkuläre Verklemmungen mit mehr als zwei Prozessen werden auch
erkannt. Beachten Sie aber, dass es eine Begrenzung der Erkennung von Verklemmungen im
Kernel gibt; siehe FEHLER.
Datensatzsperren werden durch ein explizites F_UNLCK entfernt und auch freigegeben, wenn
der Prozess sich beendet.
Datensatzsperren werden nicht von einem durch fork(2) erstellten Kind geerbt, aber über
ein execve(2) hinweg erhalten.
Aufgrund des durch die stdio(3)-Bibliothek durchgeführten Pufferns sollte die Verwendung
von Datensatzsperren mit Routinen aus diesem Paket vermieden werden; verwenden Sie
stattdessen read(2) und write(2).
Die weiter oben beschriebenen Datensatzsperren werden dem Prozess zugeordnet (anders als
die weiter unten beschriebenen Dateideskriptionssperren). Dies hat einige unglückliche
Konsequenzen:
* Falls ein Prozess irgendeinen Dateideskriptor mit Bezug zu einer Datei schließt, dann
werden alle Sperren des Prozesses für diese Datei aufgehoben, unabhängig von den
Dateideskriptor(en), mit denen diese Sperren erworben wurden. Das ist schlecht: Es
bedeutet, dass ein Prozess seine Sperren auf eine Datei wie /etc/passwd oder /etc/mtab
verlieren kann, wenn aus irgendeinem Grund eine Bibliotheksfunktion sich entscheidet,
die gleiche Datei zu öffnen, zu lesen und zu schließen.
* Die Threads in einem Prozess nutzen die Sperren gemeinsam. Mit anderen Worten, ein
Programm mit mehreren Threads kann Datensatzsperren nicht benutzen, um sicherzustellen,
dass die Threads nicht simultan auf die gleichen Regionen einer Datei zugreifen.
Offene Dateideskriptionssperren lösen beide Probleme.
Offene Dateideskriptionssperren (nicht POSIX)
Offene Dateideskriptionsperren sind empfohlene Byte-Bereichssperren, deren Funktionsweise
in den meisten Aspekten den herkömmlichen, oben beschriebenen Datensatzsperren entspricht.
Dieser Sperrtyp ist Linux-spezifisch und seit Linux 3.15 verfügbar. (Es gibt einen
Vorschlag der Austin-Gruppe, diesen Sperrtyp in die nächste Überarbeitung von POSIX.1
aufzunehmen.) Eine Erklärung offener Dateideskriptionen finden Sie in open(2).
Der Hauptunterschied zwischen den beiden Sperrtypen besteht darin, dass die herkömmlichen
Datensatzsperren mit einem Prozess verbunden sind, während Sperren offener
Dateideskriptionen mit der offenen Dateideskription verbunden sind, für die sie erlangt
wurden, ähnlich wie Sperren, die mit flock(2) erlangt wurden. Konsequenterweise (und
anders als herkömmliche empfohlene Datensatzsperren) werden Sperren offener
Dateideskriptionen über fork(2) (und clone(2) mit CLONE_FILES) geerbt und werden nur
automatisch durch das Schließen der letzten offenen Dateideskription freigegeben, statt
bei jedem Schließen der Datei.
Im Konflikt stehende Kombinationen von Sperren (d.h. eine Lese-Sperre und eine
Schreib-Sperre oder zwei Schreib-Sperren), wobei eine Sperre eine offene
Dateideskriptionssperre und die andere eine traditionelle Datensatzsperre ist, sind selbst
dann im Konflikt, wenn sie vom gleichen Prozess auf dem gleichen Dateideskriptor
aufgenommen wurden.
Offene Dateideskriptionssperren, die über die gleichen offenen Dateideskriptionen (d.h.
über den gleichen Dateideskriptor oder über durch fork(2), dup(2), fcntl() F_DUPFD und so
weiter erstellte Duplikate des Dateideskriptors) gesetzt werden, sind immer kompatibel:
Falls auf einen bereits gesperrten Bereich eine neue Sperre gesetzt wird, wird die
existierende Sperre in den neuen Sperrtyp umgewandelt. (Solche Umwandlungen können wie
oben beschrieben zum Teilen, Verkleinern oder Verschmelzen mit einer existierenden Sperre
führen.)
Auf der anderen Seite können offene Dateideskriptionssperren zueinander im Konflikt
stehen, wenn sie über verschiedene offene Dateideskriptionen erlangt wurden. Daher können
die Threads in einem Programm mit mehreren Threads offene Dateideskriptionssperren dazu
verwenden, um den Zugriff auf Dateiregionen zu koordinieren, indem jeder Thread sein
eigenes open(2) auf der Datei durchführt und die Sperren über den entstehenden
Dateideskriptor anwendet.
Wie bei herkömmlichen empfohlenen Sperren ist das dritte Argument für fcntl(), lock, ein
Zeiger auf eine flock-Struktur. Im Gegensatz zu herkömmlichen Datensatzsperren muss das
Feld l_pid dieser Struktur bei Verwendung der unterhalb beschriebenen Befehle auf Null
gesetzt werden.
Die Befehle für den Umgang mit offenen Dateideskriptionssperren sind analog zu denen, die
mit traditionellen Sperren verwandt werden:
F_OFD_SETLK (struct flock *)
Erlangt eine offene Dateideskriptionssperre (wenn l_type F_RDLCK oder F_WRLCK ist)
oder gibt eine offene Dateideskriptionssperre frei (wenn l_type F_UNLCK ist), für
die Bytes, die durch die Felder l_whence, l_start und l_len festgelegt sind. Falls
durch einen anderen Prozess eine im Konflikt stehende Sperre gehalten wird, liefert
der Aufruf -1 zurück und setzt errno auf EAGAIN.
F_OFD_SETLKW (struct flock *)
Wie bei F_OFD_SETLK, aber falls eine im Konflikt stehende Sperre auf der Datei
gehalten wird, dann wird auf die Freigabe dieser Sperre gewartet. Falls beim Warten
ein Signal gefangen wird, dann wird der Aufruf unterbrochen und (nachdem der
Signal-Handler zurückgekehrt ist) sofort zurückgekehrt (mit einem Rückgabewert -1
und errno auf EINTR gesetzt, siehe signal(7)).
F_OFD_GETLK (struct flock *)
Bei der Eingabe zu diesem Aufruf beschreibt lock eine offene
Dateideskriptionssperre, die auf der Datei gesetzt werden soll. Falls die Sperre
gesetzt werden könnte, setzt sie fcntl() nicht wirklich, sondern liefert im Feld
l_type von lock F_UNLCK zurück und lässt die anderen Felder der Struktur
unverändert. Falls eine oder mehrere inkompatible Sperren das Setzen dieser Sperre
behinderten, werden die Details über eine dieser Sperren mittels lock, wie oben für
F_GETLK beschrieben, zurückgeliefert.
In der aktuellen Implementierung wird nicht auf Verklemmungen für offene
Dateideskriptionssperren geprüft. (Dies steht im Gegensatz zu den prozessorientierten
Datensatzsperren, bei denen der Kernel eine Erkennung von Verklemmungen durchführt.)
Pflichtsperren
Warnung: Die Linux-Implementierung der Pflichtsperren ist unzuverlässig. Siehe FEHLER
unten. Aufgrund dieser Fehler und der Tatsache, dass davon ausgegangen wird, dass diese
Funktionalität wenig genutzt wird, sind die Pflichtsperren seit Linux 4.5 eine optionale
Funktionalität, die durch eine Konfigurationsoption (CONFIG_MANDATORY_FILE_LOCKING)
gesteuert werden. Dies ist der erste Schritt hin zur kompletten Entfernung dieser
Funktionalität.
Standardmäßig sind herkömmliche (prozessorientierte) und Sperren offener
Dateideskriptionsdatensätze empfohlene Sperren. Empfohlene Sperren werden nicht erzwungen
und sind nur bei der Zusammenarbeit von Prozessen nützlich.
Beide Sperrtypen können auch verpflichtend sein. Verpflichtende Sperren werden für alle
Prozesse durchgesetzt. Falls ein Prozess einen inkompatiblen Zugriff auf einen
Dateibereich versucht (z.B. read(2) oder write(2)), der eine inkompatible verpflichtende
Sperre hat, dann hängt das Ergebnis davon ab, ob der Schalter O_NONBLOCK für seine offene
Dateideskription aktiviert ist. Falls der Schalter O_NONBLOCK nicht aktiviert ist, wird
der Systemaufruf blockiert, bis die Sperre entfernt oder in einen Modus umgewandelt wurde,
der mit dem Zugriff kompatibel ist. Falls der Schalter O_NONBLOCK aktiviert ist, wird der
Systemaufruf mit dem Fehler EAGAIN fehlschlagen.
Um verpflichtende Sperren zu verwenden, müssen verpflichtende Sperren sowohl auf dem
Dateisystem, das die zu sperrende Datei enthält, aktiviert werden als auch auf der Datei
selbst. Verpflichtende Sperren werden auf Dateisystemen mit der Option »-o mand« von
mount(8) oder dem Schalter MS_MANDLOCK für mount(2) aktiviert. Verpflichtende Sperren
werden für eine Datei aktiviert, indem das Ausführrecht für die Datei entfernt und das
»set-group-ID«-Rechte-Bit aktiviert wird (siehe chmod(1) und chmod(2)).
Verpflichtende Sperren werden nicht durch POSIX spezifiziert. Einige andere Systeme
unterstützen auch verpflichtende Sperren, allerdings unterscheiden sich die Details zur
Aktivierung zwischen den Systemen.
Verlorene Sperren
Wenn eine empfohlene Sperre auf einem Netzwerkdateisystem wie NFS erlangt wird, ist es
möglich, dass die Sperre verloren geht. Die kann aufgrund administrativer Aktionen auf dem
Server oder aufgrund einer Netzwerkeinteilung (d.h. einem Verlust der Netzverbindung mit
dem Server) passieren, die so lange dauert, dass der Server annimmt, dass der Client nicht
mehr funktioniert.
Wenn das Dateisystem ermittelt, dass eine Sperre verloren gegangen ist, können zukünftige
read(2)- oder write(2)-Anfragen mit dem Fehler EIO fehlschlagen. Dieser Fehler wird
beibehalten, bis die Sperre entfernt oder der Dateideskriptor geschlossen wird. Seit Linux
3.12 passiert dies zumindest auf NFSv4 (einschließlich aller Unterversionen).
Einige UNIX-Versionen senden in diesen Fällen ein Signal (SIGLOST). Linux definiert dieses
Signal nicht und stellt keine asynchrone Benachrichtigung über verlorene Sperren bereit.
Signale verwalten
F_GETOWN, F_SETOWN, F_GETOWN_EX, F_SETOWN_EX, F_GETSIG und F_SETSIG werden zur Verwaltung
der E/A-Verfügbarkeitssignale verwandt:
F_GETOWN (void)
Liefert (als Funktionsergebnis) die Prozesskennung oder Prozessgruppe zurück, die
derzeit SIGIO- und SIGURG-Signale für Ereignisse auf Dateideskriptor fd erhält.
Prozesskennungen werden als positive Werte, Prozessgruppenkennungen als negative
Werte zurückgeliefert (siehe aber auch FEHLER unten). arg wird ignoriert.
F_SETOWN (int)
Setzt die Prozesskennung oder Prozessgruppenkennung, die SIGIO- und SIGURG-Signale
für Ereignisse auf dem Dateideskriptor fd erhalten wird. Der Zielprozess oder die
Zielprozessgruppe wird in arg festgelegt. Eine Prozesskennung wird als positiver,
eine Prozessgruppenkennung wird als negativer Wert festgelegt. Häufig legt sich der
aufrufende Prozess als der Eigentümer fest (d.h. arg wird als getpid(2)
festgelegt).
Neben dem Setzen des Dateideskriptoreigentümers muss auch die Erzeugung von
Signalen auf dem Dateideskriptor aktiviert werden. Dies erfolgt durch den Befehl
fcntl() F_SETFL, um den Dateistatusschalter SIGIO zu setzen, immer wenn Ein- oder
Ausgabe auf dem Dateideskriptor möglich wird. Der Befehl fcntl() F_SETSIG kann zum
Erhalt des Empfangs von Signalen neben SIGIO verwandt werden.
Senden von Signalen an den durch F_SETOWN festgelegten Prozesseigner (Gruppe)
unterliegt den gleichen Rechteprüfungen wie sie in kill(2) beschrieben sind, wobei
der sendende Prozess derjenige ist, der F_SETOWN einsetzt (siehe aber FEHLER
unten). Falls diese Rechteprüfung fehlschlägt, wird das Signal ohne Rückmeldung
verworfen. Hinweis: Die Aktion F_SETOWN notiert die Berechtigungen des Aufrufenden
zum Zeitpunkt des Aufrufs von fcntl() und es sind diese gespeicherten
Berechtigungen, die für die Rechteüberprüfung verwandt werden.
Falls der Dateideskriptor fd sich auf ein Socket bezieht, wählt F_SETOWN auch den
Empfänger des Signals SIGURG, das ausgeliefert wird, wenn Außerbanddaten beim
Socket eintreffen, aus. (SIGURG wird in jeder Situation gesandt, in der select(2)
berichtete, dass das Socket eine »außergewöhnliche Bedingung« habe.)
Das Folgende stimmte in 2.6.x-Kerneln bis einschließlich 2.6.11:
Falls in einem Prozess mit mehreren Threads, der mit einer
Threading-Bibliothek läuft, die Thread-Gruppen unterstützt (z.B. NPTL), ein
von Null verschiedener Wert an F_SETSIG übergeben wird, dann hat ein an
F_SETOWN übergebener positiver Wert eine andere Bedeutung: Statt eine
Prozesskennung zu sein, die einen gesamten Prozess identifiziert, ist es
eine Thread-Kennung, die einen bestimmten Prozess innerhalb des Threads
identifiziert. Konsequenterweise kann es notwendig sein, F_SETOWN das
Ergebnis von gettid(2) statt von getpid(2) zu übergeben, um vernünftige
Ergebnisse zu erhalten, wenn F_SETSIG benutzt wird. (In aktuellen
Linux-Threading-Implementierungen ist die Kennung des Haupt-Threads
identisch zu seiner Prozesskennung. Das bedeutet, dass ein Programm mit nur
einem einzigen Thread in diesem Szenario genauso gettid(2) oder getpid(2)
verwenden kann.) Beachten Sie allerdings, dass die Aussage in diesem Absatz
nicht auf das Signal SIGURG für Außerbanddaten für ein Socket zutrifft:
Dieses Signal wird immer zu einem Prozess oder einer Prozessgruppe gesandt,
abhängig vom in F_SETOWN übergebenen Wert.
Das obige Verhalten wurde in Linux 2.6.12 versehentlich deaktivert und wird nicht
mehr wiederhergestellt. Seit Linux 2.6.32 verwenden Sie F_SETOWN_EX, um die Signale
SIGIO und SIGURG auf einen bestimmten Thread anzuwenden.
F_GETOWN_EX (struct f_owner_ex *) (seit Linux 2.6.32)
Liefert die aktuellen Eigenschaften des Dateideskriptoreigentümers, wie sie von
einer vorherigen F_SETOWN_EX-Aktion definiert wurden, zurück. Die Information wird
in der Struktur, auf die arg zeigt, zurückgeliefert. Sie hat die folgende Form:
struct f_owner_ex {
int type;
pid_t pid;
};
Das Feld type wird einen der Werte F_OWNER_TID, F_OWNER_PID oder F_OWNER_PGRP
enthalten. Das Feld pid ist eine positive Ganzzahl, die die Thread-Kennung,
Prozesskennung oder Prozessgruppenkennung darstellt. Siehe F_SETOWN_EX für weitere
Details.
F_SETOWN_EX (struct f_owner_ex *) (seit Linux 2.6.32)
Diese Aktion führt eine ähnliche Aufgabe wie F_SETOWN aus. Sie erlaubt dem
Aufrufenden, E/A-Verfügbarkeitssignale zu einem bestimmten Thread, Prozess oder
einer Prozessgruppe zu dirigieren. Der Aufrufende bestimmt das Ziel der Signale
mittels arg, der ein Zeiger auf eine Struktur f_owner_ex ist. Das Feld type hat
einen der folgenden Werte, der definiert, wie pid interpretiert wird:
F_OWNER_TID
Sendet das Signal an den Thread, dessen Thread-Kennung (der von den Aufrufen
clone(2) oder gettid(2) zurückgelieferte Wert) in pid festgelegt ist.
F_OWNER_PID
Sendet das Signal an den Prozess dessen ID in pid angegeben ist.
F_OWNER_PGRP
Sendet das Signal zu der Prozessgruppe, deren Kennung in pid festgelegt ist.
(Beachten Sie, dass anders als bei F_SETOWN, eine Prozessgruppenkennung hier
als positiver Wert festgelegt ist.)
F_GETSIG (void)
Liefert (als Funktionsergebnis) das Signal zurück, das gesendet wird, wenn Ein-
oder Ausgabe möglich wird. Ein Wert von Null bedeutet, dass SIGIO gesandt wird.
Jeder andere Wert (einschließlich SIGIO) ist stattdessen das gesandt Signal. In
diesem Fall sind zusätzliche Informationen im Signal-Handler verfügbar, falls er
mit SA_SIGINFO installiert wurde. arg wird ignoriert.
F_SETSIG (int)
Setzt das gesandte Signal, wenn Ein- oder Ausgabe möglich wird, auf den in arg
angegebenen Wert. Ein Wert von Null bedeutet, das Vorgabesignal SIGIO zu senden.
Jeder andere Wert (einschließlich SIGIO) ist das stattdessen zu sendende Signal und
in diesem Fall sind zusätzliche Informationen im Signal-Handler verfügbar, falls
dieser mit SA_SIGINFO installiert wurde.
Durch Verwendung von F_SETSIG mit einem von Null verschiedenen Wert und Setzen von
SA_SIGINFO für den Signal-Handler (siehe sigaction(2)) werden Zusatzinformationen
über E/A-Ereignisse an den Handler in einer Struktur siginfo_t übergeben. Falls das
Feld si_code anzeigt, dass die Quelle SI_SIGIO ist, gibt das Feld si_fd den mit
diesem Ereignis korrelierten Dateideskriptor zurück. Andernfalls gibt es keine
Anzeichen, welche Dateideskriptoren wartend sind und Sie sollten die normalen
Mechanismen (select(2), poll(2), read(2) mit gesetztem O_NONBLOCK usw.) verwenden,
um herauszufinden, welche Dateideskriptoren für E/A verfügbar sind.
Beachten Sie, dass der in si_fd bereitgestellte Dateideskriptor derjenige ist, der
in der Aktion F_SETSIG festgelegt wurde. Dies kann zu ungewöhnlichen Grenzfällen
führen. Falls der Dateideskriptor dupliziert wird (dup(2) oder ähnlich) und der
ursprüngliche Dateideskriptor geschlossen wird, dann werden E/A-Ereignisse
weiterhin generiert aber das Feld si_fd wird die Anzahl der jetzt geschlossenen
Dateideskriptoren enthalten.
Durch Auswahl von Echtzeitsignalen (Wert >= SIGRTMIN), können mehrere
E/A-Ereignisse unter Verwendung der gleichen Signalnummer in eine Warteschlange
eingereiht werden. (Einreihung in Warteschlangen hängt vom verfügbaren Speicher
ab). Falls wie oben SA_SIGINFO für den Signal-Handler gesetzt ist, sind zusätzliche
Informationen verfügbar.
Beachten Sie, dass Linux eine Begrenzung für die Anzahl der Echtzeitsignale
erzwingt, die für einen Prozess in eine Warteschlange eingereiht werden (siehe
getrlimit(2) und signal(7)). Falls diese Begrenzung erreicht ist, kehrt der Kernel
zur Auslieferung von SIGIO zurück und dieses Signal wird dem gesamten Prozess statt
nur einem bestimmten Thread ausgeliefert.
Mittels dieser Mechanismen kann ein Programm eine komplett asynchrone E/A implementieren,
ohne (in den meisten Fällen) select(2) oder poll(2) zu verwenden.
Die Verwendung von O_ASYNC ist für BSD und Linux spezifisch. Die einzige in POSIX.1
spezifizierte Verwendung von F_GETOWN and F_SETOWN ist im Zusammenhang mit der Verwendung
des Signals SIGURG bei Sockets. (POSIX spezifiziert das Signal SIGIO nicht). POSIX enthält
asynchrone E/A und auch die Struktur aio_sigevent, um ähnliche Dinge zu erreichen; diese
sind unter Linux auch als Teil der GNU-C-Bibliothek (Glibc) verfügbar.
Ausleihe
F_SETLEASE und F_GETLEASE (Linux 2.4 und neuer) werden dazu verwandt, für die offene
Dateideskription, auf den der Dateideskriptor fd verweist, eine Ausleihe (»lease«) zu
etablieren und die aktuelle Ausleihe zu ermitteln. Ein Datei-Ausleihe stellt einen
Mechanismus bereit, durch den ein Prozess, der die Ausleihe hält (der »Ausleiher«) über
die Auslieferung eines Signals benachrichtigt wird, wenn ein Prozess (der
»Ausleihe-Brecher«) versucht, die von diesem Dateideskriptor referenzierte Datei mit
open(2) zu öffen oder mit truncate(2) zu verkleinern/vergrößern.
F_SETLEASE (int)
Setzt oder entfernt eine Datei-Ausleihe, abhängig davon, welcher der folgenden Wert
in der Ganzzahl arg angegeben ist:
F_RDLCK
Nimmt eine Lese-Ausleihe heraus. Dies führt dazu, dass der aufrufende
Prozess informiert wird, wenn die Datei zum Schreiben geöffnet oder
abgeschnitten wird. Eine Lese-Ausleihe kann nur auf einen Dateideskriptor
gelegt werden, der nur-lesbar geöffnet ist.
F_WRLCK
Nimmt eine Schreibe-Ausleihe heraus. Dies führt dazu, dass der aufrufende
Prozess informiert wird, wenn die Datei zum Lesen oder Schreiben geöffnet
oder abgeschnitten wird. Eine Schreibe-Ausleihe kann nur auf eine Datei
gelegt werden, falls es keine anderen offenen Dateideskriptoren für diese
Datei gibt.
F_UNLCK
Unsere Ausleihe von einer Datei entfernen.
Ausleihen sind einem offenen Dateideskriptor zugeordnet (siehe open(2)). Das bedeutet,
dass ein duplizierter Dateideskriptor (zum Beispiel durch fork(2) oder dup(2) erstellt)
sich auf die gleiche Ausleihe bezieht und dass diese Ausleihe durch jeden dieser
Deskriptoren verändert oder freigegeben werden kann. Desweiteren werden Ausleihen durch
eine explizite Aktion F_UNLCK auf einem dieser duplizierten Dateideskriptoren freigegeben
oder wenn alle solchen Dateideskriptoren geschlossen wurden.
Ausleihen dürfen nur für reguläre Dateien herausgenommen werden. Ein nicht privilegierter
Prozess darf eine Ausleihe nur für Dateien herausnehmen, deren UID (Eigentümer) auf die
Dateisystem-UID des Prozesses passt. Ein Prozess mit der Capability CAP_LEASE darf
Ausleihen für beliebige Dateien herausnehmen.
F_GETLEASE (void)
Zeigt den Typ der Ausleihe, der dem Dateideskriptor fd zugeordnet ist, an, indem
entweder F_RDLCK, F_WRLCK oder F_UNLCK zurückgeliefert wird, das respektive eine
Lese-, Schreib- oder keine Ausleihe anzeigt. arg wird ignoriert.
Wenn ein Prozess (der »Ausleihe-Brecher«) ein open(2) oder truncate(2) durchführt, der mit
einer mittels F_SETLEASE etablierten Ausleihe in Konflikt steht, wird der Systemaufruf
durch den Kernel blockiert und der Kernel informiert den Ausleihenden, indem er ihm ein
Signal (standardmäßig SIGIO) sendet. Der Ausleihende sollte reagieren, indem er alle
notwendigen Aufräumarbeiten durchführt, um den Zugriff des anderen Prozesses auf die Datei
vorzubereiten (z.B. das Rausschreiben von zwischengespeicherten Puffern). Danach sollte er
entweder seine Ausleihe entfernen oder runterstufen. Eine Ausleihe wird durch Ausführung
des Befehls F_SETLEASE mit der Angabe von arg als F_UNLCK entfernt. Falls der Ausleihende
derzeit eine Schreib-Ausleihe auf die Datei hält und der Ausleih-Brecher die Datei zum
Lesen öffnet, dann reicht es aus, wenn der Ausleihende seine Ausleihe auf eine
Lese-Ausleihe herunterstuft. Dies erfolgt durch Ausführung des Befehls F_SETLEASE mit der
Angabe von arg als F_RDLCK.
Falls der Ausleihende nicht innerhalb der in /proc/sys/fs/lease-break-time festgelegten
Anzahl von Sekunden seine Ausleihe herunterstuft oder entfernt, entfernt der Kernel die
Ausleihe des Ausleihenden zwangsweise oder stuft sie zwangsweise herunter.
Sobald ein Ausleih-Brechen eingeleitet wurde, liefert F_GETLEASE den Ziel-Ausleihtyp
(entweder F_RDLCK oder F_UNLCK, abhängig davon, was zum Ausleih-Brecher kompatibel wäre)
zurück, bis der Ausleihende freiwillig seine Ausleihe herunterstuft oder entfernt oder der
Kernel dies zwangsweise tut, nachdem die Ausleih-Brechzeit abgelaufen ist.
Sobald die Ausleihe freiwillig oder zwangsweise entfernt oder heruntergestuft wurde und
unter der Annahme, dass der Ausleih-Brecher nicht den Systemaufruf entblockiert hat,
erlaubt der Kernel dem Systemaufruf des Ausleih-Brechers fortzufahren.
Falls das vom Ausleih-Brecher blockierte open(2) oder truncate(2) durch einen
Signal-Handler unterbrochen wird, schlägt der Systemaufruf mit dem Fehler EINTR fehl, aber
die anderen Schritte erfolgen dennoch wie oben beschrieben. Falls der Ausleih-Brecher
durch ein Signal getötet wird, während er in open(2) oder truncate(2) blockiert ist,
erfolgen die anderen Schritte dennoch wie oben beschrieben. Falls der Ausleih-Brecher den
Schalter O_NONBLOCK beim Aufruf von open(2) festgelegt hat, schlägt der Aufruf sofort mit
dem Fehler EWOULDBLOCK fehl, aber die anderen Schritte erfolgen dennoch wie oben
beschrieben.
Standardmäßig wird das Signal SIGIO zur Information des Ausleihenden verwandt, dies kann
aber mit dem Befehl F_SETSIG von fcntl() geändert werden. Falls ein Befehl F_SETSIG
ausgeführt wird (selbst einer, der SIGIO festlegt) und der Singal-Handler mittels
SA_SIGINFO etabliert wurde, dann wird der Handler eine Struktur siginfo_t als sein zweites
Argument erhalten und das Feld si_fd dieses Argumentes wird den Dateideskriptor der Datei
mit der Ausleihe, auf die ein anderer Prozess zugegriffen hat, enthalten. (Dies ist
nützlich, falls der Aufrufende Ausleihen für mehrere Dateien hält.)
Datei- und Verzeichnis-Änderungsbenachrichtigung (dnotify)
F_NOTIFY (int)
(Seit Linux 2.4) Stellt Benachrichtigungen bereit, wenn das durch fd referenzierte
Verzeichnis oder eine der darin enthaltenen Dateien geändert wird. Die Ereignisse,
für die benachrichtigt wird, werden in arg festgelegt. Dies ist eine Bitmaske, in
der mittels ODER eines oder mehrere der folgenden Bits festgelegt sind:
DN_ACCESS Ein Dateizugriff erfolgte (read(2), pread(2), readv(2) und ähnliche)
DN_MODIFY Eine Datei wurde verändert (write(2), pwrite(2), writev(2),
truncate(2), ftruncate(2) und ähnliche).
DN_CREATE Eine Datei wurde erstellt (open(2), creat(2), mknod(2), mkdir(2),
link(2), symlink(2), rename(2) in dieses Verzeichnis).
DN_DELETE Der Link auf eine Datei wurde entfernt (unlink(2), rename(2) in ein
anderes Verzeichnis, rmdir(2)).
DN_RENAME Eine Datei wurde innerhalb dieses Verzeichnis umbenannt (rename(2)).
DN_ATTRIB Die Attribute einer Datei wurden geändert (chown(2), chmod(2),
utime(2), utimensat(2) und ähnliche).
(Um diese Definitionen zu erhalten, muss das Feature-Test-Makro _GNU_SOURCE vor der
Einbindung irgendeiner Header-Datei definiert werden.)
Verzeichnisbenachrichtigungen sind normalerweise »einmalig« und die Anwendung muss
sich erneut registrieren, um weitere Benachrichtigungen zu erhalten. Wird
alternativ DN_MULTISHOT in arg aufgenommen, bleiben die Benachrichtigungen aktiv,
bis sie explizit entfernt werden.
Eine Reihe von F_NOTIFY-Anfragen ist kumulativ, bei der die Ereignisse in arg zu
der Menge der bereits beobachteten hinzugefügt werden. Um Benachrichtigungen für
alle Ereignisse zu deaktivieren, führen Sie einen Aufruf F_NOTIFY mit arg als 0
durch.
Benachrichtigungen erfolgen über die Zustellung eines Signals. Das Standardsignal
ist SIGIO, dies kann aber mittels des Befehls F_SETSIG von fcntl() geändert werden.
(Beachten Sie, dass SIGIO eines der nichtwarteschlangenfähigen Standardsignale ist;
wird auf Echtzeitsignale umgestellt, können mehrere Benachrichtigungen für den
Prozess in die Warteschlange gestellt werden). Im letzteren Falle erhält der
Signal-Handler eine Struktur siginfo_t als zweites Argument (falls der Hanndler
mittels SA_SIGINFO etabliert wurde) und das Feld si_fd dieser Struktur enthält
einen Dateideskriptor, der die Benachrichtigung erstellte (nützlich, falls
Benachrichtigungen für mehrere Verzeichnisse eingerichtet werden).
Insbesondere bei der Verwendung von DN_MULTISHOT sollte ein Echtzeitsignal für die
Benachrichtigung verwandt werden, so dass mehrere Benachrichtigungen in die
Warteschlange aufgenommen werden können.
HINWEIS: Neue Anwendungen sollten die Schnittstelle inotify (verfügbar seit Kernel
2.6.13) verwenden, die eine deutlich überlegene Schnittstelle zur Ermittlung von
Benachrichtigungen über Dateisystemereignisse bietet. Siehe inotify(7).
Ändern der Kapazität einer Pipe
F_SETPIPE_SZ (int; seit Linux 2.6.35)
Ändert die Kapazität der durch fd referenzierten Pipe auf mindestens arg Byte. Ein
unprivilegierter Prozess kann die Pipe-Kapazität auf jeden Wert zwischen der
Systemseitengröße und der durch /proc/sys/fs/pipe-max-size (siehe proc(5))
definierten Grenze anpassen. Wird versucht, die Pipe-Kapazität unter die
Seitengröße zu setzen, dann wird diese ohne Rückmeldung auf die Seitengröße
gerundet. Versucht ein unprivilegierter Prozess, die Pipe-Kapazität über die in
/proc/sys/fs/pipe-max-size definierte Grenze zu setzen, führt dies zu dem Fehler
EPERM; ein privilegierter Prozess (CAP_SYS_RESOURCE) kann die Grenze außer Kraft
setzen.
Beim Reservieren des Puffers für die Pipe darf der Kernel eine größere Kapazität
als arg verwenden, falls das für die Implementierung passend ist. (In der aktuellen
Implementierung ist die Allokation die nächst-größere Zweierpotenz des Vielfachen
der Seitengröße der angeforderten Größe.) Die tatsächliche gesetzte Kapazität (in
Byte) wird als Ergebnis der Funktion zurückgeliefert.
Wird versucht, die Pipe-Kapazität auf einen Wert zu setzen, der kleiner als der
derzeit zum Speichern von Daten verwandte Pufferbereich ist, dann wird der Fehler
EBUSY erzeugt.
F_GETPIPE_SZ (void; seit Linux 2.6.35)
Liefert (als Ergebnis der Funktion) die Kapazität der durch fd referenzierten Pipe
zurück.
Versiegelung von Dateien
Dateisiegel begrenzen die Menge der erlaubten Aktionen für eine bestimmte Datei. Für jedes
auf eine Datei angebrachte Siegel wird von jetzt an eine bestimmte Gruppe an Aktionen auf
dieser Datei mit dem Fehler EPERM fehlschlagen. Die Datei wird als versiegelt bezeichnet.
Die Vorgabemenge der Siegel hängt von der Art der unterliegenden Datei und dem Dateisystem
ab. Für einen Überblick über Dateiversiegelung, einer Diskussion ihres Zwecks und
Code-Beispiele siehe memfd_create(2).
Derzeit können Dateisiegel nur auf durch memfd_create(2) zurückgelieferte
Dateideskriptoren angewandt werden (falls MFD_ALLOW_SEALING eingesetzt wurde). Auf anderen
Dateisystemen werden alle fcntl()-Aktionen zur Versiegelung EINVAL zurückliefern.
Siegel sind eine Eigenschaft eines Inodes. Daher verfügen alle offenen Dateideskriptoren,
die auf den gleichen Inode verweisen, über die gleiche Gruppe an Siegeln. Desweiteren
können Siegel nie entfernt, nur hinzugefügt werden.
F_ADD_SEALS (int; seit Linux 3.17)
Fügt die im Bitmasken-Argument arg übergebenen Siegel zu der Gruppe der Siegel des
Inodes, der vom Dateideskriptor fd referenziert wird, hinzu. Siegel können nicht
mehr entfernt werden. Sobald dieser Aufruf gelingt, werden die Siegel sofort vom
Kernel durchgesetzt. Falls die derzeitige Gruppe der Siegel F_SEAL_SEAL enthält
(siehe unten) wird dieser Aufruf mit EPERM abgelehnt. Hinzufügen eines bereits
gesetzten Siegels ist eine Nullaktion, falls F_SEAL_SEAL nicht bereits gesetzt ist.
Um ein Siegel zu setzen, muss der Dateideskriptor fd schreibbar sein.
F_GET_SEALS (void; seit Linux 3.17)
Liefert (als Funktionsergebnis) die aktuelle Menge der Siegel des durch fd
referenzierten Inodes zurück. Falls keine Siegel gesetzt sind, wird 0
zurückgeliefert. Falls die Datei Versiegelung nicht unterstützt, wird -1
zurückgeliefert und errno auf EINVAL gesetzt.
Die folgenden Versiegelungen sind verfügbar:
F_SEAL_SEAL
Falls dieses Siegel gesetzt ist, wird jeder zukünftige Aufruf von fcntl() mit
F_ADD_SEALS mit dem Fehler EPERM fehlschlagen. Daher verhindert dieses Siegel jede
Änderung an der Siegelmenge selbst. Falls die ursprüngliche Siegelmenge einer Datei
F_SEAL_SEAL enthält, dann führt dies effektiv dazu, dass die Siegelmenge konstant
und gesperrt ist.
F_SEAL_SHRINK
Falls dieses Siegel gesetzt ist, kann die in Frage kommende Datei nicht verkleinert
werden. Dies betrifft open(2) mit dem Schalter O_TRUNC sowie truncate(2) und
ftruncate(2). Diese Aufrufe schlagen mit EPERM fehl, falls Sie versuchen, die in
Frage kommende Datei zu verkleinern. Vergrößern der Datei ist weiterhin möglich.
F_SEAL_GROW
Falls dieses Siegel gesetzt ist, kann die in Frage kommende Datei nicht vergrößert
werden. Dies betrifft write(2) über das Ende der Datei hinaus, truncate(2),
ftruncate(2) und fallocate(2). Diese Aufrufe schlagen mit EPERM fehl, falls Sie
versuchen, diese zum Vergrößern der Datei zu verwenden. Falls Sie die Dateigröße
beibehalten oder verkleinern, werden diese Aufrufe weiterhin wie erwartet
funktionieren.
F_SEAL_WRITE
If this seal is set, you cannot modify the contents of the file. Note that
shrinking or growing the size of the file is still possible and allowed. Thus, this
seal is normally used in combination with one of the other seals. This seal affects
write(2) and fallocate(2) (only in combination with the FALLOC_FL_PUNCH_HOLE
flag). Those calls fail with EPERM if this seal is set. Furthermore, trying to
create new shared, writable memory-mappings via mmap(2) will also fail with EPERM.
Using the F_ADD_SEALS operation to set the F_SEAL_WRITE seal fails with EBUSY if
any writable, shared mapping exists. Such mappings must be unmapped before you can
add this seal. Furthermore, if there are any asynchronous I/O operations
(io_submit(2)) pending on the file, all outstanding writes will be discarded.
Datei Lese-/Schreibehinweise
Der Kernel kann mit Schreib-Lebenszeithinweisen über die erwartete relative Lebenszeit von
Schreiboperationen an einer benannten Inode oder über eine bestimmte offene
Dateideskription informiert werden (Siehe open(2) für eine Erläuterung von offenen
Dateideskriptoren.). In diesem Kontext bedeutet der Ausdruck »Schreib-Lebenszeit«, die
erwartete Zeit, die die Daten auf dem Medium verbleiben, bevor sie überschrieben oder
gelöscht werden.
Eine Anwendung darf die unten festgelegten verschiedenen Hinweisewerte verwenden, um die
Schreiboperationen in verschiedene Schreibklassen zu trennen, so dass mehrere Benutzer
oder Anwendungen, die mit dem gleichen Speicher-Backend arbeiten, ihre E/A-Muster in einer
konsistenten Art zusammenfassen können. Allerdings implizieren diese Schalter keine
funktionalen Semantiken und verschiedene E/A-Klassen können die Schreib-Lebenszeithinweise
in beliebigen Arten benutzen, so lange die Hinweise konsistent benutzt werden.
Die folgenden Aktionen könen auf den Dateideskriptor fd angewandt werden:
F_GET_RW_HINT (uint64_t *; seit Linux 4.13)
Liefert den Wert des Lese-/Schreibhinweises, der der durch fd referenzierten
unterliegenden Inode zugeordnet ist.
F_SET_RW_HINT (uint64_t *; seit Linux 4.13)
Setzt den Wert des Lese-/Schreibhinweises, der der durch fd referenzierten
unterliegenden Inode zugeordnet ist. Dieser Hinweis verbleibt, bis er entweder
explizit geändert oder das unterliegende Dateisystem ausgehängt wird.
F_GET_FILE_RW_HINT (uint64_t *; seit Linux 4.13)
Liefert den Wert des Lese-/Schreibhinweises, der der durch fd referenzierten
offenen Dateideskription zugeordnet ist.
F_SET_FILE_RW_HINT (uint64_t *; seit Linux 4.13)
Setzt den Wert des Lese-/Schreibhinweises, der der durch fd referenzierten offenen
Dateideskription zugeordnet ist.
Falls einer offenen Dateideskription noch kein Lese-/Schreibhinweis zugeordnet wurde, dann
soll der der Inode zugeordnete Wert verwandt werden, falls vorhanden.
Die folgenden Lese-/Schreibhinweise sind seit Linux 4.13 gültig:
RWH_WRITE_LIFE_NOT_SET
Es wurde kein spezieller Hinweis gesetzt. Dies ist der Vorgabewert.
RWH_WRITE_LIFE_NONE
Kein spezielle Schreib-Lebenszeit ist dieser Datei oder diesem Inode zugeordnet.
RWH_WRITE_LIFE_SHORT
Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen
Dateideskriptor geschrieben werden, eine kurze Lebenszeit haben werden.
RWH_WRITE_LIFE_MEDIUM
Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen
Dateideskriptor geschrieben werden, eine längere Lebenszeit als Daten, die mit
RWH_WRITE_LIFE_SHORT geschrieben wurden, haben werden.
RWH_WRITE_LIFE_LONG
Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen
Dateideskriptor geschrieben werden, eine längere Lebenszeit als Daten, die mit
RWH_WRITE_LIFE_MEDIUM geschrieben wurden, haben werden.
RWH_WRITE_LIFE_EXTREME
Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen
Dateideskriptor geschrieben werden, eine längere Lebenszeit als Daten, die mit
RWH_WRITE_LIFE_LONG geschrieben wurden, haben werden.
Alle schreibspezifischen Hinweise sind relativ zueinander und ihnen sollte keine
individuelle absolute Bedeutung beigemessen werden.
RÜCKGABEWERT
Die Rückgabewerte sind abhängig von der ausgeführten Operation:
F_DUPFD Der neue Dateideskriptor.
F_GETFD Wert des File-Deskriptor-Schalters.
F_GETFL Wert der Dateistatusschalter.
F_GETLEASE
Art der Ausleihe, die auf dem Dateideskriptor gehalten wird.
F_GETOWN Wert des Dateideskriptor-Eigentümers.
F_GETSIG Wert des Signals, wenn Lesen oder Schreiben möglich wird, oder Null für
traditionelles SIGIO-Verhalten.
F_GETPIPE_SZ, F_SETPIPE_SZ
Die Kapazität der Pipe.
F_GET_SEALS
Eine Bitmaske, die die Siegel identifiziert, die für den durch fd referenzierten
Inode gesetzt wurden.
Alle anderen Befehle
Null.
Bei einem Fehler wird -1 zurückgegeben und errno entsprechend gesetzt.
FEHLER
EACCES oder EAGAIN
Aktion wird durch von anderen Prozessen gehaltene Sperren verhindert.
EAGAIN The operation is prohibited because the file has been memory-mapped by another
process.
EBADF fd ist kein offener Dateideskriptor.
EBADF cmd ist F_SETLK oder F_SETLKW und der Öffnungsmodus des Dateideskriptors passt
nicht auf die angeforderte Art der Sperre.
EBUSY cmd ist F_SETPIPE_SZ und die in arg festgelegte neue Kapazität der Pipe ist kleiner
als die Größe des derzeit zur Speicherung von Daten in der Pipe verwandten
Pufferspeichers.
EBUSY cmd is F_ADD_SEALS, arg includes F_SEAL_WRITE, and there exists a writable, shared
mapping on the file referred to by fd.
EDEADLK
Es wurde erkannt, dass der angegebene Befehl F_SETLKW zu einer Verklemmung führen
würde.
EFAULT lock befindet sich außerhalb Ihres adressierbaren Adressraums.
EINTR cmd ist F_SETLKW oder F_OFD_SETLKW und die Aktion wurde durch ein Signal
unterbrochen; siehe signal(7).
EINTR cmd ist F_GETLK, F_SETLK, F_OFD_GETLK oder F_OFD_SETLK und die Aktion wurde durch
ein Signal unterbrochen, bevor die Sperre geprüft oder erworben werden konnte.
Passiert am wahrscheinlichsten beim Sperren von Dateien in der Ferne (d.h. Sperren
über NFS), kann aber manchmal auch lokal auftreten.
EINVAL Der in cmd angegebene Wert wird von diesem Kernel nicht erkannt.
EINVAL cmd ist F_ADD_SEALS und arg enthält ein nicht erkanntes Versiegelungs-Bit.
EINVAL cmd ist F_ADD_SEALS oder F_GET_SEALS und das Dateisystem, das den durch fd
referenzierten Inode enthält, unterstützt kein Versiegeln.
EINVAL cmd ist F_DUPFD und arg ist negativ oder ist größer als der maximal zulässige Wert
(siehe die Diskussion von RLIMIT_NOFILE in getrlimit(2)).
EINVAL cmd ist F_SETSIG und arg ist keine erlaubbare Signalnummer.
EINVAL cmd ist F_OFD_SETLK, F_OFD_SETLKW oder F_OFD_GETLK und l_pid wurde nicht als Null
angegeben.
EMFILE cmd ist F_DUPFD und die Beschränkung pro Prozess für die Anzahl offener
Dateideskriptoren wurde erreicht.
ENOLCK Zu viele Segment-Sperren offen, die Sperr-Tabelle ist voll oder ein Sperrprotokoll
aus der Ferne schlug fehl (z.B. Sperren über NFS).
ENOTDIR
F_NOTIFY wurde in cmd angegeben, aber fd zeigt nicht auf ein Verzeichnis.
EPERM cmd ist F_SETPIPE_SZ und die weiche oder harte Benutzer-Pipe-Beschränkung wurde
erreicht; siehe pipe(7).
EPERM Es wurde versucht, den Schalter O_APPEND auf einer Datei zurückzusetzen, bei der
das Attribut »nur anhängen« gesetzt ist.
EPERM cmd war F_ADD_SEALS aber fd war nicht zum Schreiben offen oder die aktuelle Menge
der Siegel der Datei enthält bereits F_SEAL_SEAL.
KONFORM ZU
SVr4, 4.3BSD, POSIX.1-2001. Nur die Operationen F_DUPFD, F_GETFD, F_SETFD, F_GETFL,
F_SETFL, F_GETLK, F_SETLK und F_SETLKW sind in POSIX.1-2001 spezifiziert.
F_GETOWN und F_SETOWN sind in POSIX.1-2001 spezifiziert. (Um Ihre Definitionen zu
erhalten, definieren Sie entweder _XOPEN_SOURCE mit einem Wert größer oder gleich 500 oder
definieren Sie _POSIX_C_SOURCE mit einem Wert größer oder gleich 200809L.)
F_DUPFD_CLOEXEC ist in POSIX.1-2001 spezifiziert. (Um diese Definitionen zu erhalten,
definieren Sie _POSIX_C_SOURCE mit einem Wert größer oder gleich 200809L oder
_XOPEN_SOURCE mit einem Wert größer oder gleich 700.)
F_GETOWN_EX, F_SETOWN_EX, F_SETPIPE_SZ, F_GETPIPE_SZ, F_GETSIG, F_SETSIG, F_NOTIFY,
F_GETLEASE und F_SETLEASE sind Linux-spezifisch. (Definieren Sie das Makro _GNU_SOURCE, um
diese Definitionen zu erhalten.)
F_OFD_SETLK, F_OFD_SETLKW und F_OFD_GETLK sind Linux-spezifisch (und _GNU_SOURCE muss
definiert werden, um ihre Definitionen zu erhalten). Es wird aber daran gearbeitet, dass
sie in der nächsten Version von POSIX.1 enthalten sind.
F_ADD_SEALS und F_GET_SEALS sind Linux-spezifisch.
ANMERKUNGEN
Die Fehler, die von dup2(2) zurückgegeben werden, sind anders als die von F_DUPFD.
Sperrung von Dateien
Der ursprüngliche Systemaufruf fcntl() von Linux war nicht dafür konstruiert, große
Dateiversätze (in der Struktur flock) zu handhaben. Konsequenterweise wurde ein
Systemaufruf fcntl64() in Linux 2.4 hinzugefügt. Dieser neuere Systemaufruf setzt eine
andere Struktur zum Sperren von Dateien ein, flock64, und entsprechende Befehle F_GETLK64,
F_SETLK64 und F_SETLKW64. Diese Details können allerdings von Anwendungen, die Glibc
einsetzen, ignoriert werden, da dessen Wrapperfunktion fcntl() transparent den neueren
Systemaufruf einsetzt, wo er verfügbar ist.
Datensatzsperren
Seit Kernel 2.0 gibt es keine Wechselwirkung zwischen den durch flock(2) und fcntl()
gesetzten Sperrtypen.
Bei einer Reihe von Systemen gibt es in struct flock weitere Felder wie z.B. l_sysid. Es
ist klar, dass l_pid alleine nicht sehr nützlich ist, falls der Prozess, der die Sperre
hält, auf einer anderen Maschine existiert.
Der ursprüngliche Systemaufruf fcntl() von Linux war nicht dafür konstruiert, große
Dateiversätze (in der Struktur flock) zu handhaben. Konsequenterweise wurde ein
Systemaufruf fcntl64() in Linux 2.4 hinzugefügt. Dieser neuere Systemaufruf setzt eine
andere Struktur zum Sperren von Dateien ein, flock64, und entsprechende Befehle F_GETLK64,
F_SETLK64 und F_SETLKW64. Diese Details können allerdings von Anwendungen, die Glibc
einsetzen, ignoriert werden, da dessen Wrapperfunktion fcntl() transparent den neueren
Systemaufruf einsetzt, wo er verfügbar ist.
Datensatzsperren und NFS
Falls ein NFSv4-Client vor Linux 3.12 den Kontakt mit dem Server für eine bestimmte
Zeitperiode (definiert als mehr als 90 Sekunden ohne Kommunikation) verlor, konnte er eine
Sperre verlieren und wieder erlangen, ohne von dieser Tatsache Kenntnis zu erhalten. (Die
Zeitperiode, nach der der Kontakt als verloren angesehen wird, ist als NFSv4-Ausleihzeit
bekannt. Auf einem Linux-NFS-Server kann diese durch einen Blick in
/proc/fs/nfsd/nfsv4leasetime, die diese Periode in Sekunden ausdrückt, bestimmt werden.
Der Vorgabewert für diese Datei ist 90.) In diesem Szenario sind potenziell
Datenbeschädigungen möglich, da ein anderer Prozess in der Zwischenzeit eine Sperre
erlangen und Datei-E/A durchführen könnte.
Wenn seit Linux 3.12 ein NFSv4-Client den Kontakt mit dem Server verliert, wird jede E/A
des Prozesses, der »glaubt«, er halte eine Sperre, fehlschlagen, bis dieser Prozess die
Datei schließt und erneut öffnet. Ein Kernelparameter (nfs.recover_lost_locks) kann auf 1
gesetzt werden, um das pre-3.12-Verhalten zu erreichen, bei dem ein Client versuchen wird,
verloren gegangene Sperren wiederherzustellen, wenn der Kontakt mit dem Server wieder
etabliert ist. Aufgrund des vorhandenen Risikos der Datenverfälschung ist die Vorgabe für
diesen Parameter 0 (deaktiviert).
FEHLER
F_SETFL
Es ist nicht möglich, F_SETFL zum Ändern des Zustands der Schalter O_DSYNC und O_SYNC zu
verwenden. Versuche, den Zustand dieser Schalter zu ändern, werden ohne Meldung ignoriert.
F_GETOWN
Eine Begrenzung der Linux-Systemaufrufkonventionen auf einigen Architekturen (insbesondere
i386) bedeutet, dass, falls eine von F_GETOWN zurückgelieferte (negative)
Prozessgruppen-ID in den Bereich -1 bis -4095 fällt, dies von Glibc fälschlicherweise als
Fehler im Systemaufruf interpretiert wird. Dann wird der Rückgabewert von fcntl() -1 sein
und errno wird die (positive) Prozessgruppen-ID enthalten. Die Linux-spezifische Aktion
F_GETOWN_EX vermeidet dieses Problem. Seit Glibc Version 2.11 versteckt Glibc das
Kernelproblem F_GETOWN, indem F_GETOWN mittels F_GETOWN_EX implementiert wird.
F_SETOWN
Unter Linux 2.4 und älter gibt es einen Fehler, der auftreten kann, wenn ein
unprivilegierter Prozess statt einem Aufrufenden F_SETOWN verwendet, um den Eigentümer
eines Socket-Dateideskriptors als Prozess(gruppe) festzulegen. In diesem Fall kann fcntl()
-1 mit errno auf EPERM gesetzt zurückliefern, selbst wenn der/die
Eigentümerprozess(gruppe) dergestalt ist, dass der Aufrufende Rechte hat, ihr/ihm Signale
zu senden. Trotz dieses zurückgelieferten Fehlers wird der Dateieigentümer gesetzt und
Signale werden zum Eigentümer gesandt.
Erkennung von Verklemmungen
Der vom Kernel eingesetzte Algorithmus zur Erkennung von Verklemmungen beim Umgang mit
F_SETLKW kann sowohl falsch-negative (keine Erkennung von Verklemmungen, eine Gruppe von
verklemmten Prozessen bleibt unbegrenzt blockiert) als auch falsch-positive
(EDEADLK-Fehler obwohl keine Verklemmung vorliegt) liefern. Beispielsweise begrenzt der
Kernel die Sperrtiefe seiner Abhängigkeitssuche auf 10 Schritte, was bedeutet, dass
zirkulare Verklemmungsketten, die diese Größe überschreiten, nicht erkannt werden.
Zusätzlich kann der Kernel fälschlicherweise eine Verklemmung erkennen, wenn zwei oder
mehr Prozesse, die mit dem Schalter CLONE_FILES von clone(2) Sperren setzen, die (dem
Kernel) als im Konflikt stehend erscheinen.
Pflichtsperren
Die Linux-Implementierung von Pflichtsperren ist Gegenstand von Ressourcenwettläufen, die
sie unzuverlässig machen: Ein write(2)-Aufruf, der sich mit einer Sperre überschneidet,
kann Daten verändern, nachdem die Pflichtsperre erlangt wurde. Ein read(2)-Aufruf, der
sich mit einer Sperre überschneidet, kann Änderungen an Daten entdecken, die nur
vorgenommen wurden, nachdem eine Schreibsperre erlangt wurde. Ähnliche Wettläufe gibt es
zwischen Pflichtsperren und mmap(2). Daher ist es nicht zu empfehlen, sich auf
Pflichtsperren zu verlassen.
SIEHE AUCH
dup2(2), flock(2), open(2), socket(2), lockf(3), capabilities(7), feature_test_macros(7),
lslocks(8)
locks.txt, mandatory-locking.txt und dnotify.txt in dem Linux-Kernelquelldateiverzeichnis
Documentation/filesystems/. (Bei älteren Kerneln befinden sich diese Dateien direkt unter
dem Verzeichnis Documentation/ und mandatory-locking.txt heißt mandatory.txt.)
KOLOPHON
Diese Seite ist Teil der Veröffentlichung 4.15 des Projekts Linux-man-pages. Eine
Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die
aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Schulze
<joey@infodrom.org>, Helge Kreutzmann <debian@helgefjell.de> und Chris Leick
<c.leick@vollbio.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG
übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an <debian-l10n-german@lists.debian.org>.