.\" -*- 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 .\" Modified 1995-09-26 by Andries Brouwer .\" and again on 960413 and 980804 and 981223. .\" Modified 1998-12-11 by Jamie Lokier .\" Applied correction by Christian Ehrhardt - aeb, 990712 .\" Modified 2002-04-23 by Michael Kerrisk .\" 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 .\" Modified description of file leases: fixed some errors of detail .\" Replaced the term "lease contestant" by "lease breaker" .\" Modified, 27 May 2004, Michael Kerrisk .\" 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 , 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 , .\" 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 .\" Document F_ADD_SEALS and F_GET_SEALS .\" 2017-06-26, Jens Axboe .\" 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 "5. Februar 2023" "Linux man\-pages 6.03" .SH BEZEICHNUNG fcntl \- Dateideskriptoren manipulieren .SH BIBLIOTHEK Standard\-C\-Bibliothek (\fIlibc\fP, \fI\-lc\fP) .SH ÜBERSICHT .nf \fB#include \fP .PP \fBint fcntl(int \fP\fIdd\fP\fB, int \fP\fIBef\fP\fB, … /* \fP\fIarg\fP\fB */ );\fP .fi .SH BESCHREIBUNG \fBfcntl\fP() führt eine der unten beschriebenen Aktionen auf dem offenen Dateideskriptor \fIdd\fP aus. Die Aktion wird durch \fIBef\fP festgelegt. .PP \fBfcntl\fP() kann ein optionales drittes Argument akzeptieren. Ob dieses Argument notwendig ist, ergibt sich durch \fIBef\fP. Der benötigte Argumenttyp wird nach jedem \fIBef\fP\-Namen in Klammern angedeutet (in den meisten Fällen ist der benötigte Typ \fIint\fP und der Argumenttyp wird mit dem Namen \fIarg\fP identifiziert). Falls das Argument nicht notwendig ist, wird \fIvoid\fP angegeben. .PP 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 \fBfcntl\fP() mit dem gewünschten Wert von \fIBef\fP und dem anschließenden Test, ob der Aufruf mit \fBEINVAL\fP fehlschlug, wodurch angezeigt wird, dass der Kernel diesen Wert nicht unterstützt. .SS "Duplizieren eines Dateideskriptors" .TP \fBF_DUPFD\fP (\fIint\fP) verdoppelt den Dateideskriptor \fIdd\fP unter Verwendung des Dateideskriptors mit der kleinsten Nummer, die identisch zu oder größer als \fIarg\fP ist. Dies unterscheidet sich von \fBdup2\fP(2), das exakt den angegebenen Dateideskriptor verwendet. .IP Bei Erfolg wird der neue Dateideskriptor zurückgegeben. .IP Lesen Sie \fBdup\fP(2) für weitere Details. .TP \fBF_DUPFD_CLOEXEC\fP (\fIint\fP; seit Linux 2.6.24) Wie für \fBF_DUPFD\fP, 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 \fBfcntl\fP()\-\fBF_SETFD\fP\-Aktion zu vermeiden, um den Schalter \fBFD_CLOEXEC\fP zu setzen. Für eine Erläuterung, warum dieser Schalter nützlich ist, lesen Sie die Beschreibung von \fBO_CLOEXEC\fP in \fBopen\fP(2). .SS Datei\-Deskriptor\-Schalter Die folgenden Befehle verändern die einem Dateideskriptor zugeordneten Schalter. Derzeit ist nur ein solcher Schalter definiert: \fBFD_CLOEXEC\fP, der »close\-on\-exec«\-Schalter. Falls das \fBFD_CLOEXEC\fP\-Bit gesetzt ist, wird der Dateideskriptor automatisch bei einem erfolgreichen \fBexecve\fP(2) geschlossen. (Falls der \fBexecve\fP(2) fehlschlägt, bleibt der Dateideskriptor offen.) Falls das Bit \fBFD_CLOEXEC\fP nicht gesetzt ist, wird der Dateideskriptor über ein \fBexecve\fP(2) hinweg offen bleiben. .TP \fBF_GETFD\fP (\fIvoid\fP) Liefert (als Ergebnis der Funktion) die Dateideskriptorschalter; \fIarg\fP wird ignoriert. .TP \fBF_SETFD\fP (\fIint\fP) Setzt den Dateideskriptorschalter auf den durch \fIarg\fP angegebenen Wert. .PP In Programmen mit mehreren Threads ist die Verwendung von \fBfcntl\fP() \fBF_SETFD\fP, um den Schalter »close\-on\-exec« zum gleichen Zeitpunkt zu setzen, zu dem ein anderer Thread ein \fBfork\fP(2) mit einem \fBexecve\fP(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 \fBO_CLOEXEC\fP in \fBopen\fP(2) für Details und wie dem Problem abgeholfen werden kann. .SS Dateistatusschalter .\" or .\" .BR creat (2), Jede offene Dateideskription hat bestimmte zugeordnete Statusschalter, die durch \fBopen\fP(2) initialisiert und möglicherweise durch \fBfcntl\fP() verändert werden. Duplizierte Dateideskriptoren (mit \fBdup\fP(2), \fBfcntl\fP(F_DUPFD), \fBfork\fP(2) usw. erstellte) beziehen sich auf die gleiche offene Dateideskription und teilen sich daher die gleichen Dateistatusschalter. .PP Die Dateistatusschalter und deren Bedeutung sind in \fBopen\fP(2) beschrieben. .TP \fBF_GETFL\fP (\fIvoid\fP) Liefert (als Ergebnis der Funktion) den Dateizugriffsmodus und die Dateistatusschalter; \fIarg\fP wird ignoriert. .TP \fBF_SETFL\fP (\fIint\fP) Setzt die Dateistatusschalter auf den durch \fIarg\fP angegebenen Wert. Dateizugriffsmodus (\fBO_RDONLY\fP, \fBO_WRONLY\fP, \fBO_RDWR\fP) und Dateierzeugungsschalter (d.h. \fBO_CREAT\fP, \fBO_EXCL\fP, \fBO_NOCTTY\fP, \fBO_TRUNC\fP) werden in \fIarg\fP ignoriert. Unter Linux kann dieser Befehl nur die Schalter \fBO_APPEND\fP, \fBO_ASYNC\fP, \fBO_DIRECT\fP, \fBO_NOATIME\fP und \fBO_NONBLOCK\fP ändern. Es ist nicht möglich, die Schalter \fBO_DSYNC\fP und \fBO_SYNC\fP zu ändern, siehe FEHLER weiter unten. .SS "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. .PP \fBF_SETLK\fP, \fBF_SETLKW\fP und \fBF_GETLK\fP 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, \fIlock\fP, ist ein Zeiger auf eine Struktur, die mindestens die folgende Felder (in einer nicht festgelegten Reihenfolge) enthält: .PP .in +4n .EX 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) */ … }; .EE .in .PP Die Felder \fIl_whence\fP, \fIl_start\fP und \fIl_len\fP 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. .PP \fIl_start\fP ist der Startversatz für die Sperre und wird relativ zu einem der folgenden interpretiert: Dem Anfang der Datei (falls \fIl_whence\fP \fBSEEK_SET\fP ist), dem aktuellen Dateiversatz (falls \fIl_whence\fP \fBSEEK_CUR\fP ist) oder dem Ende der Datei (falls \fIl_whence\fP \fBSEEK_END\fP ist). In den abschließenden zwei Fällen kann \fIl_start\fP eine negative Zahl sein, vorausgesetzt, der Versatz liegt nicht vor dem Anfang der Datei. .PP \fIl_len\fP legt die Anzahl der zu sperrenden Bytes fest. Falls \fIl_len\fP positiv ist, wird der zu sperrende Bereich die Bytes \fIl_start\fP bis einschließlich \fIl_start\fP+\fIl_len\fP\-1 umfassen. Die Angabe von 0 für \fIl_len\fP hat eine besondere Bedeutung: Alle Bytes beginnend bei \fIl_whence\fP und \fIl_start\fP bis zum Ende der Datei sperren, unabhängig davon, wie groß die Datei anwächst. .PP POSIX.1\-2001 erlaubt (verlangt es aber nicht), dass eine Implementierung einen negativen Wert für \fIl_len\fP unterstützt. Falls \fIl_len\fP negativ ist, deckt das durch \fIlock\fP beschriebene Intervall die Bytes \fIl_start\fP+\fIl_len\fP bis zu einschließlich \fIl_start\fP\-1 ab. Dies wird durch Linux seit 2.4.21 und 2.5.49 unterstützt. .PP Das Feld \fIl_type\fP kann dazu verwandt werden, eine Lese\- (\fBF_RDLCK\fP) oder Schreibsperre (\fBF_WRLCK\fP) 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.) .TP \fBF_SETLK\fP (\fIstruct flock *\fP) Erlangt (wenn \fIl_type\fP \fBF_RDLCK\fP oder \fBF_WRLCK\fP ist) oder gibt eine Sperre (wenn \fIl_type\fP \fBF_UNLCK\fP ist) für die durch die Felder \fIl_whence\fP, \fIl_start\fP und \fIl_len\fP von \fIlock\fP festgelegten Bytes ab. Falls durch einen anderen Prozess eine im Konflikt stehende Sperre gehalten wird, liefert dieser Aufruf \-1 zurück und setzt \fIerrno\fP auf \fBEACCES\fP oder \fBEAGAIN\fP. (Der in diesem Fall zurückgelieferte Fehler unterscheidet sich zwischen Implementierungen, daher verlangt POSIX, dass portable Anwendungen auf beide Fehler prüfen.) .TP \fBF_SETLKW\fP (\fIstruct flock *\fP) Wie für \fBF_SETLK\fP, 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 \fIerrno\fP auf \fBEINTR\fP gesetzt; siehe \fBsignal\fP(7)). .TP \fBF_GETLK\fP (\fIstruct flock *\fP) Als Eingabe zu diesem Aufruf beschreibt \fIlock\fP eine Sperre, die auf diese Datei angewandt werden soll. Falls die Sperre angewandt werden könnte, setzt \fBfcntl\fP() diese nicht wirklich, sondern liefert \fBF_UNLCK\fP in dem Feld \fIl_type\fP von \fIlock\fP und lässt die anderen Felder dieser Struktur unverändert. .IP Falls eine oder mehrere inkompatible Sperren das Setzen dieser Sperre verhinderten, dann liefert \fBfcntl\fP() Details über eine dieser Sperren in den Feldern \fIl_type\fP, \fIl_whence\fP, \fIl_start\fP und \fIl_len\fP von \fIlock\fP zurück. Falls die im Konflikt stehende Sperre eine traditionelle (Prozess\-orientierte) Datensatzsperre ist, dann wird das Feld \fIl_pid\fP auf die PID des Prozesses gesetzt, der die Sperre hält. Falls die in Konflikt stehende Sperre eine offene Dateideskriptionssperre ist, dann wird \fIl_pid\fP auf \-1 gesetzt. Beachten Sie, dass die zurückgelieferte Information zum Zeitpunkt der Analyse durch den Aufrufenden bereits veraltet sein kann. .PP Um eine Lesesperre zu setzen, muss \fIdd\fP zum Lesen offen sein. Um eine Schreibsperre zu setzen, muss \fIdd\fP zum Schreiben offen sein. Um beide Typen setzen zu können, öffnen Sie eine Datei lese\- und schreibbar. .PP Wenn Sperren mit \fBF_SETLKW\fP gesetzt werden, erkennt der Kernel \fIVerklemmungen\fP, 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 \fBF_SETLKW\fP 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 \fBEDEADLK\fP 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. .PP Datensatzsperren werden durch ein explizites \fBF_UNLCK\fP entfernt und auch freigegeben, wenn der Prozess sich beendet. .PP Datensatzsperren werden nicht von einem durch \fBfork\fP(2) erstellten Kind geerbt, aber über ein \fBexecve\fP(2) hinweg erhalten. .PP Aufgrund des durch die \fBstdio\fP(3)\-Bibliothek durchgeführten Pufferns sollte die Verwendung von Datensatzsperren mit Routinen aus diesem Paket vermieden werden; verwenden Sie stattdessen \fBread\fP(2) und \fBwrite\fP(2). .PP Die weiter oben beschriebenen Datensatzsperren werden dem Prozess zugeordnet (anders als die weiter unten beschriebenen Dateideskriptionssperren). Dies hat einige unglückliche Konsequenzen: .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 ().) Falls ein Prozess \fIirgendeinen\fP 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 \fI/etc/passwd\fP oder \fI/etc/mtab\fP verlieren kann, wenn aus irgendeinem Grund eine Bibliotheksfunktion sich entscheidet, die gleiche Datei zu öffnen, zu lesen und zu schließen. .IP \[bu] 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. .PP Offene Dateideskriptionssperren lösen beide Probleme. .SS "Offene Dateideskriptionssperren (nicht POSIX)" .\" FIXME . Review progress into POSIX .\" http://austingroupbugs.net/view.php?id=768 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 \fBopen\fP(2). .PP 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 \fBflock\fP(2) erlangt wurden. Konsequenterweise (und anders als herkömmliche empfohlene Datensatzsperren) werden Sperren offener Dateideskriptionen über \fBfork\fP(2) (und \fBclone\fP(2) mit \fBCLONE_FILES\fP) geerbt und werden nur automatisch durch das Schließen der letzten offenen Dateideskription freigegeben, statt bei jedem Schließen der Datei. .PP 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. .PP Offene Dateideskriptionssperren, die über die gleichen offenen Dateideskriptionen (d.h. über den gleichen Dateideskriptor oder über durch \fBfork\fP(2), \fBdup\fP(2), \fBfcntl\fP() \fBF_DUPFD\fP 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.) .PP 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 \fBopen\fP(2) auf der Datei durchführt und die Sperren über den entstehenden Dateideskriptor anwendet. .PP Wie bei herkömmlichen empfohlenen Sperren ist das dritte Argument für \fBfcntl\fP(), \fIlock\fP, ein Zeiger auf eine \fIflock\fP\-Struktur. Im Gegensatz zu herkömmlichen Datensatzsperren muss das Feld \fIl_pid\fP dieser Struktur bei Verwendung der unterhalb beschriebenen Befehle auf Null gesetzt werden. .PP Die Befehle für den Umgang mit offenen Dateideskriptionssperren sind analog zu denen, die mit traditionellen Sperren verwandt werden: .TP \fBF_OFD_SETLK\fP (\fIstruct flock *\fP) Erlangt eine offene Dateideskriptionssperre (wenn \fIl_type\fP \fBF_RDLCK\fP oder \fBF_WRLCK\fP ist) oder gibt eine offene Dateideskriptionssperre frei (wenn \fIl_type\fP \fBF_UNLCK\fP ist), für die Bytes, die durch die Felder \fIl_whence\fP, \fIl_start\fP und \fIl_len\fP festgelegt sind. Falls durch einen anderen Prozess eine im Konflikt stehende Sperre gehalten wird, liefert der Aufruf \-1 zurück und setzt \fIerrno\fP auf \fBEAGAIN\fP. .TP \fBF_OFD_SETLKW\fP (\fIstruct flock *\fP) Wie bei \fBF_OFD_SETLK\fP, 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 \fIerrno\fP auf \fBEINTR\fP gesetzt, siehe \fBsignal\fP(7)). .TP \fBF_OFD_GETLK\fP (\fIstruct flock *\fP) Bei der Eingabe zu diesem Aufruf beschreibt \fIlock\fP eine offene Dateideskriptionssperre, die auf der Datei gesetzt werden soll. Falls die Sperre gesetzt werden könnte, setzt sie \fBfcntl\fP() nicht wirklich, sondern liefert im Feld \fIl_type\fP von \fIlock\fP \fBF_UNLCK\fP 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 \fIlock\fP, wie oben für \fBF_GETLK\fP beschrieben, zurückgeliefert. .PP .\" commit 57b65325fe34ec4c917bc4e555144b4a94d9e1f7 .\" 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.) .SS Pflichtsperren \fIWarnung\fP: 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 (\fBCONFIG_MANDATORY_FILE_LOCKING\fP) gesteuert werden. In Linux 5.15 und neuer wird diese Funktionalität nicht mehr unterstützt. .PP 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. .PP 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. \fBread\fP(2) oder \fBwrite\fP(2)), der eine inkompatible verpflichtende Sperre hat, dann hängt das Ergebnis davon ab, ob der Schalter \fBO_NONBLOCK\fP für seine offene Dateideskription aktiviert ist. Falls der Schalter \fBO_NONBLOCK\fP 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 \fBO_NONBLOCK\fP aktiviert ist, wird der Systemaufruf mit dem Fehler \fBEAGAIN\fP fehlschlagen. .PP 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 \fBmount\fP(8) oder dem Schalter \fBMS_MANDLOCK\fP für \fBmount\fP(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 \fBchmod\fP(1) und \fBchmod\fP(2)). .PP .\" 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. .SS "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. .PP .\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d Wenn das Dateisystem ermittelt, dass eine Sperre verloren gegangen ist, können zukünftige \fBread\fP(2)\- oder \fBwrite\fP(2)\-Anfragen mit dem Fehler \fBEIO\fP 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). .PP .\" Einige UNIX\-Versionen senden in diesen Fällen ein Signal (\fBSIGLOST\fP). Linux definiert dieses Signal nicht und stellt keine asynchrone Benachrichtigung über verlorene Sperren bereit. .SS "Signale verwalten" \fBF_GETOWN\fP, \fBF_SETOWN\fP, \fBF_GETOWN_EX\fP, \fBF_SETOWN_EX\fP, \fBF_GETSIG\fP und \fBF_SETSIG\fP werden zur Verwaltung der E/A\-Verfügbarkeitssignale verwandt: .TP \fBF_GETOWN\fP (\fIvoid\fP) Liefert (als Funktionsergebnis) die Prozess\- oder Prozessgruppenkennung zurück, die derzeit \fBSIGIO\fP\- und \fBSIGURG\fP\-Signale für Ereignisse auf Dateideskriptor \fIdd\fP erhält. Prozesskennungen werden als positive Werte, Prozessgruppenkennungen als negative Werte zurückgeliefert (siehe aber auch FEHLER unten). \fIarg\fP wird ignoriert. .TP \fBF_SETOWN\fP (\fIint\fP) Setzt die Prozesskennung oder Prozessgruppenkennung, die \fBSIGIO\fP\- und \fBSIGURG\fP\-Signale für Ereignisse auf dem Dateideskriptor \fIdd\fP erhalten wird. Der Zielprozess oder die Zielprozessgruppe wird in \fIarg\fP angegeben. Eine Prozesskennung wird als positiver, eine Prozessgruppenkennung wird als negativer Wert angegeben. Häufig legt sich der aufrufende Prozess als der Eigentümer fest (d.h. \fIarg\fP wird als \fBgetpid\fP(2) angegeben). .IP Neben dem Setzen des Dateideskriptoreigentümers muss auch die Erzeugung von Signalen auf dem Dateideskriptor aktiviert werden. Dies erfolgt durch den Befehl \fBfcntl\fP() \fBF_SETFL\fP, um den Dateistatusschalter \fBSIGIO\fP zu setzen, immer wenn Ein\- oder Ausgabe auf dem Dateideskriptor möglich wird. Der Befehl \fBfcntl\fP() \fBF_SETSIG\fP kann zum Erhalt des Empfangs von Signalen neben \fBSIGIO\fP verwandt werden. .IP Senden von Signalen an den durch \fBF_SETOWN\fP festgelegten Prozesseigner (Gruppe) unterliegt den gleichen Rechteprüfungen wie sie in \fBkill\fP(2) beschrieben sind, wobei der sendende Prozess derjenige ist, der \fBF_SETOWN\fP einsetzt (siehe aber FEHLER unten). Falls diese Rechteprüfung fehlschlägt, wird das Signal ohne Rückmeldung verworfen. \fIHinweis\fP: Die Aktion \fBF_SETOWN\fP notiert die Berechtigungen des Aufrufenden zum Zeitpunkt des Aufrufs von \fBfcntl\fP() und es sind diese gespeicherten Berechtigungen, die für die Rechteüberprüfung verwandt werden. .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. Falls der Dateideskriptor \fIdd\fP sich auf ein Socket bezieht, wählt \fBF_SETOWN\fP auch den Empfänger des Signals \fBSIGURG\fP, das ausgeliefert wird, wenn Außerbanddaten beim Socket eintreffen, aus. (\fBSIGURG\fP wird in jeder Situation gesandt, in der \fBselect\fP(2) berichtete, dass das Socket eine »außergewöhnliche Bedingung« habe.) .IP Das Folgende stimmte in Linux 2.6.x bis einschließlich Linux 2.6.11: .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) 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 \fBF_SETSIG\fP übergeben wird, dann hat ein an \fBF_SETOWN\fP ü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, \fBF_SETOWN\fP das Ergebnis von \fBgettid\fP(2) statt von \fBgetpid\fP(2) zu übergeben, um vernünftige Ergebnisse zu erhalten, wenn \fBF_SETSIG\fP 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 \fBgettid\fP(2) oder \fBgetpid\fP(2) verwenden kann.) Beachten Sie allerdings, dass die Aussage in diesem Absatz nicht auf das Signal \fBSIGURG\fP für Außerbanddaten für ein Socket zutrifft: Dieses Signal wird immer zu einem Prozess oder einer Prozessgruppe gesandt, abhängig vom in \fBF_SETOWN\fP übergebenen Wert. .RE .IP Das obige Verhalten wurde in Linux 2.6.12 versehentlich deaktiviert und wird nicht mehr wiederhergestellt. Seit Linux 2.6.32 verwenden Sie \fBF_SETOWN_EX\fP, um die Signale \fBSIGIO\fP und \fBSIGURG\fP auf einen bestimmten Thread anzuwenden. .TP \fBF_GETOWN_EX\fP (\fIstruct f_owner_ex *\fP) (seit Linux 2.6.32) Liefert die aktuellen Eigenschaften des Dateideskriptoreigentümers, wie sie von einer vorherigen \fBF_SETOWN_EX\fP\-Aktion definiert wurden, zurück. Die Information wird in der Struktur, auf die \fIarg\fP zeigt, zurückgeliefert. Sie hat die folgende Form: .IP .in +4n .EX struct f_owner_ex { int type; pid_t pid; }; .EE .in .IP Das Feld \fItype\fP wird einen der Werte \fBF_OWNER_TID\fP, \fBF_OWNER_PID\fP oder \fBF_OWNER_PGRP\fP enthalten. Das Feld \fIpid\fP ist eine positive Ganzzahl, die die Thread\-Kennung, Prozesskennung oder Prozessgruppenkennung darstellt. Siehe \fBF_SETOWN_EX\fP für weitere Details. .TP \fBF_SETOWN_EX\fP (\fIstruct f_owner_ex *\fP) (seit Linux 2.6.32) Diese Aktion führt eine ähnliche Aufgabe wie \fBF_SETOWN\fP 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 \fIarg\fP, der ein Zeiger auf eine Struktur \fIf_owner_ex\fP ist. Das Feld \fItype\fP hat einen der folgenden Werte, der definiert, wie \fIpid\fP interpretiert wird: .RS .TP \fBF_OWNER_TID\fP Sendet das Signal an den Thread, dessen Thread\-Kennung (der von den Aufrufen \fBclone\fP(2) oder \fBgettid\fP(2) zurückgelieferte Wert) in \fIpid\fP festgelegt ist. .TP \fBF_OWNER_PID\fP Sendet das Signal an den Prozess dessen ID in \fIpid\fP angegeben ist. .TP \fBF_OWNER_PGRP\fP Sendet das Signal zu der Prozessgruppe, deren Kennung in \fIpid\fP festgelegt ist. (Beachten Sie, dass anders als bei \fBF_SETOWN\fP, eine Prozessgruppenkennung hier als positiver Wert festgelegt ist.) .RE .TP \fBF_GETSIG\fP (\fIvoid\fP) Liefert (als Funktionsergebnis) das Signal zurück, das gesendet wird, wenn Ein\- oder Ausgabe möglich wird. Ein Wert von Null bedeutet, dass \fBSIGIO\fP gesandt wird. Jeder andere Wert (einschließlich \fBSIGIO\fP) ist stattdessen das gesandt Signal. In diesem Fall sind zusätzliche Informationen im Signal\-Handler verfügbar, falls er mit \fBSA_SIGINFO\fP installiert wurde. \fIarg\fP wird ignoriert. .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. Setzt das gesandte Signal, wenn Ein\- oder Ausgabe möglich wird, auf den in \fIarg\fP angegebenen Wert. Ein Wert von Null bedeutet, das Vorgabesignal \fBSIGIO\fP zu senden. Jeder andere Wert (einschließlich \fBSIGIO\fP) ist das stattdessen zu sendende Signal und in diesem Fall sind zusätzliche Informationen im Signal\-Handler verfügbar, falls dieser mit \fBSA_SIGINFO\fP installiert wurde. .IP Durch Verwendung von \fBF_SETSIG\fP mit einem von Null verschiedenen Wert und Setzen von \fBSA_SIGINFO\fP für den Signal\-Handler (siehe \fBsigaction\fP(2)) werden Zusatzinformationen über E/A\-Ereignisse an den Handler in einer Struktur \fIsiginfo_t\fP übergeben. Falls das Feld \fIsi_code\fP anzeigt, dass die Quelle \fBSI_SIGIO\fP ist, gibt das Feld \fIsi_fd\fP den mit diesem Ereignis korrelierten Dateideskriptor zurück. Andernfalls gibt es keine Anzeichen, welche Dateideskriptoren wartend sind und Sie sollten die normalen Mechanismen (\fBselect\fP(2), \fBpoll\fP(2), \fBread\fP(2) mit gesetztem \fBO_NONBLOCK\fP usw.) verwenden, um herauszufinden, welche Dateideskriptoren für E/A verfügbar sind. .IP Beachten Sie, dass der in \fIsi_fd\fP bereitgestellte Dateideskriptor derjenige ist, der in der Aktion \fBF_SETSIG\fP festgelegt wurde. Dies kann zu ungewöhnlichen Grenzfällen führen. Falls der Dateideskriptor dupliziert wird (\fBdup\fP(2) oder ähnlich) und der ursprüngliche Dateideskriptor geschlossen wird, dann werden E/A\-Ereignisse weiterhin generiert aber das Feld \fIsi_fd\fP wird die Anzahl der jetzt geschlossenen Dateideskriptoren enthalten. .IP Durch Auswahl von Echtzeitsignalen (Wert >= \fBSIGRTMIN\fP), 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 \fBSA_SIGINFO\fP für den Signal\-Handler gesetzt ist, sind zusätzliche Informationen verfügbar. .IP .\" See fs/fcntl.c::send_sigio_to_task() (2.4/2.6) sources -- MTK, Apr 05 Beachten Sie, dass Linux eine Begrenzung für die Anzahl der Echtzeitsignale erzwingt, die für einen Prozess in eine Warteschlange eingereiht werden (siehe \fBgetrlimit\fP(2) und \fBsignal\fP(7)). Falls diese Begrenzung erreicht ist, kehrt der Kernel zur Auslieferung von \fBSIGIO\fP zurück und dieses Signal wird dem gesamten Prozess statt nur einem bestimmten Thread ausgeliefert. .PP Mittels dieser Mechanismen kann ein Programm eine komplett asynchrone E/A implementieren, ohne (in den meisten Fällen) \fBselect\fP(2) oder \fBpoll\fP(2) zu verwenden. .PP Die Verwendung von \fBO_ASYNC\fP ist für BSD und Linux spezifisch. Die einzige in POSIX.1 spezifizierte Verwendung von \fBF_GETOWN\fP and \fBF_SETOWN\fP ist im Zusammenhang mit der Verwendung des Signals \fBSIGURG\fP bei Sockets. (POSIX spezifiziert das Signal \fBSIGIO\fP nicht). POSIX enthält asynchrone E/A und auch die Struktur \fIaio_sigevent\fP, um ähnliche Dinge zu erreichen; diese sind unter Linux auch als Teil der GNU\-C\-Bibliothek (Glibc) verfügbar. .SS Ausleihe \fBF_SETLEASE\fP und \fBF_GETLEASE\fP (Linux 2.4 und neuer) werden dazu verwandt, für die offene Dateideskription, auf den der Dateideskriptor \fIdd\fP 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 \fBopen\fP(2) zu öffen oder mit \fBtruncate\fP(2) zu verkleinern/vergrößern. .TP \fBF_SETLEASE\fP (\fIint\fP) Setzt oder entfernt eine Datei\-Ausleihe, abhängig davon, welcher der folgenden Wert in der Ganzzahl \fIarg\fP angegeben ist: .RS .TP \fBF_RDLCK\fP .\" The following became true in Linux 2.6.10: .\" See the man-pages-2.09 Changelog for further info. 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. .TP \fBF_WRLCK\fP 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. .TP \fBF_UNLCK\fP Unsere Ausleihe von einer Datei entfernen. .RE .PP Ausleihen sind einem offenen Dateideskriptor zugeordnet (siehe \fBopen\fP(2)). Das bedeutet, dass ein duplizierter Dateideskriptor (zum Beispiel durch \fBfork\fP(2) oder \fBdup\fP(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 \fBF_UNLCK\fP auf einem dieser duplizierten Dateideskriptoren freigegeben oder wenn alle solchen Dateideskriptoren geschlossen wurden. .PP 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 \fBCAP_LEASE\fP darf Ausleihen für beliebige Dateien herausnehmen. .TP \fBF_GETLEASE\fP (\fIvoid\fP) Zeigt den Typ der Ausleihe, der dem Dateideskriptor \fIdd\fP zugeordnet ist, an, indem entweder \fBF_RDLCK\fP, \fBF_WRLCK\fP oder \fBF_UNLCK\fP zurückgeliefert wird, das respektive eine Lese\-, Schreib\- oder keine Ausleihe anzeigt. \fIarg\fP wird ignoriert. .PP Wenn ein Prozess (der »Ausleihe\-Brecher«) ein \fBopen\fP(2) oder \fBtruncate\fP(2) durchführt, der mit einer mittels \fBF_SETLEASE\fP 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 \fBSIGIO\fP) 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 \fBF_SETLEASE\fP mit der Angabe von \fIarg\fP als \fBF_UNLCK\fP 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 \fBF_SETLEASE\fP mit der Angabe von \fIarg\fP als \fBF_RDLCK\fP. .PP Falls der Ausleihende nicht innerhalb der in \fI/proc/sys/fs/lease\-break\-time\fP festgelegten Anzahl von Sekunden seine Ausleihe herunterstuft oder entfernt, entfernt der Kernel die Ausleihe des Ausleihenden zwangsweise oder stuft sie zwangsweise herunter. .PP Sobald ein Ausleih\-Brechen eingeleitet wurde, liefert \fBF_GETLEASE\fP den Ziel\-Ausleihtyp (entweder \fBF_RDLCK\fP oder \fBF_UNLCK\fP, 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 der Ausleih\-Brech\-Timer abgelaufen ist. .PP 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. .PP Falls das vom Ausleih\-Brecher blockierte \fBopen\fP(2) oder \fBtruncate\fP(2) durch einen Signal\-Handler unterbrochen wird, schlägt der Systemaufruf mit dem Fehler \fBEINTR\fP fehl, aber die anderen Schritte erfolgen dennoch wie oben beschrieben. Falls der Ausleih\-Brecher durch ein Signal getötet wird, während er in \fBopen\fP(2) oder \fBtruncate\fP(2) blockiert ist, erfolgen die anderen Schritte dennoch wie oben beschrieben. Falls der Ausleih\-Brecher den Schalter \fBO_NONBLOCK\fP beim Aufruf von \fBopen\fP(2) angegeben hat, schlägt der Aufruf sofort mit dem Fehler \fBEWOULDBLOCK\fP fehl, aber die anderen Schritte erfolgen dennoch wie oben beschrieben. .PP Standardmäßig wird das Signal \fBSIGIO\fP zur Information des Ausleihenden verwandt, dies kann aber mit dem Befehl \fBF_SETSIG\fP von \fBfcntl\fP() geändert werden. Falls ein Befehl \fBF_SETSIG\fP ausgeführt wird (selbst einer, der \fBSIGIO\fP festlegt) und der Singal\-Handler mittels \fBSA_SIGINFO\fP etabliert wurde, dann wird der Handler eine Struktur \fIsiginfo_t\fP als sein zweites Argument erhalten und das Feld \fIsi_fd\fP 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.) .SS "Datei\- und Verzeichnis\-Änderungsbenachrichtigung (dnotify)" .TP \fBF_NOTIFY\fP (\fIint\fP) (Seit Linux 2.4) Stellt Benachrichtigungen bereit, wenn das durch \fIdd\fP referenzierte Verzeichnis oder eine der darin enthaltenen Dateien geändert wird. Die Ereignisse, für die benachrichtigt wird, werden in \fIarg\fP angegeben. Dies ist eine Bitmaske, in der mittels ODER eines oder mehrere der folgenden Bits festgelegt sind: .PP .RS .PD 0 .TP \fBDN_ACCESS\fP Ein Dateizugriff erfolgte (\fBread\fP(2), \fBpread\fP(2), \fBreadv\fP(2) und ähnliche). .TP \fBDN_MODIFY\fP Eine Datei wurde verändert (\fBwrite\fP(2), \fBpwrite\fP(2), \fBwritev\fP(2), \fBtruncate\fP(2), \fBftruncate\fP(2) und ähnliche). .TP \fBDN_CREATE\fP Eine Datei wurde erstellt (\fBopen\fP(2), \fBcreat\fP(2), \fBmknod\fP(2), \fBmkdir\fP(2), \fBlink\fP(2), \fBsymlink\fP(2), \fBrename\fP(2) in dieses Verzeichnis). .TP \fBDN_DELETE\fP Der Link auf eine Datei wurde entfernt (\fBunlink\fP(2), \fBrename\fP(2) in ein anderes Verzeichnis, \fBrmdir\fP(2)). .TP \fBDN_RENAME\fP Eine Datei wurde innerhalb dieses Verzeichnis umbenannt (\fBrename\fP(2)). .TP \fBDN_ATTRIB\fP Die Attribute einer Datei wurden geändert (\fBchown\fP(2), \fBchmod\fP(2), \fButime\fP(2), \fButimensat\fP(2) und ähnliche). .PD .RE .IP (Um diese Definitionen zu erhalten, muss das Feature\-Test\-Makro \fB_GNU_SOURCE\fP vor der Einbindung \fIirgendeiner\fP Header\-Datei definiert werden.) .IP Verzeichnisbenachrichtigungen sind normalerweise »einmalig« und die Anwendung muss sich erneut registrieren, um weitere Benachrichtigungen zu erhalten. Wird alternativ \fBDN_MULTISHOT\fP in \fIarg\fP aufgenommen, bleiben die Benachrichtigungen aktiv, bis sie explizit entfernt werden. .IP .\" The following does seem a poor API-design choice... Eine Reihe von \fBF_NOTIFY\fP\-Anfragen ist kumulativ, bei der die Ereignisse in \fIarg\fP zu der Menge der bereits beobachteten hinzugefügt werden. Um Benachrichtigungen für alle Ereignisse zu deaktivieren, führen Sie einen Aufruf \fBF_NOTIFY\fP mit \fIarg\fP als 0 durch. .IP Benachrichtigungen erfolgen über die Zustellung eines Signals. Das Standardsignal ist \fBSIGIO\fP, dies kann aber mittels des Befehls \fBF_SETSIG\fP von \fBfcntl\fP() geändert werden. (Beachten Sie, dass \fBSIGIO\fP 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 \fIsiginfo_t\fP als zweites Argument (falls der Hanndler mittels \fBSA_SIGINFO\fP etabliert wurde) und das Feld \fIsi_fd\fP dieser Struktur enthält einen Dateideskriptor, der die Benachrichtigung erstellte (nützlich, falls Benachrichtigungen für mehrere Verzeichnisse eingerichtet werden). .IP Insbesondere bei der Verwendung von \fBDN_MULTISHOT\fP sollte ein Echtzeitsignal für die Benachrichtigung verwandt werden, so dass mehrere Benachrichtigungen in die Warteschlange aufgenommen werden können. .IP \fBHINWEIS\fP: Neue Anwendungen sollten die Schnittstelle \fIinotify\fP (verfügbar seit Linux 2.6.13) verwenden, die eine deutlich überlegene Schnittstelle zur Ermittlung von Benachrichtigungen über Dateisystemereignisse bietet. Siehe \fBinotify\fP(7). .SS "Ändern der Kapazität einer Pipe" .TP \fBF_SETPIPE_SZ\fP (\fIint\fP; seit Linux 2.6.35) Ändert die Kapazität der durch \fIdd\fP referenzierten Pipe auf mindestens \fIarg\fP Byte. Ein unprivilegierter Prozess kann die Pipe\-Kapazität auf jeden Wert zwischen der Systemseitengröße und der durch \fI/proc/sys/fs/pipe\-max\-size\fP (siehe \fBproc\fP(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 \fI/proc/sys/fs/pipe\-max\-size\fP definierte Grenze zu setzen, führt dies zu dem Fehler \fBEPERM\fP; ein privilegierter Prozess (\fBCAP_SYS_RESOURCE\fP) kann die Grenze außer Kraft setzen. .IP Beim Reservieren des Puffers für die Pipe darf der Kernel eine größere Kapazität als \fIarg\fP 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. .IP 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 \fBEBUSY\fP erzeugt. .IP Beachten Sie, dass aufgrund der Art, wie die Seiten des Pipe\-Puffers eingesetzt werden, wenn Daten in die Pipe geschrieben werden, die Anzahl der Bytes geringer als die nominale Größe sein kann, abhängig von der Größe der Schreibvorgänge. .TP \fBF_GETPIPE_SZ\fP (\fIvoid\fP; seit Linux 2.6.35) .\" Liefert (als Ergebnis der Funktion) die Kapazität der durch \fIdd\fP referenzierten Pipe zurück. .SS "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 \fBEPERM\fP 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 \fBmemfd_create\fP(2). .PP Derzeit können Dateisiegel nur auf durch \fBmemfd_create\fP(2) zurückgelieferte Dateideskriptoren angewandt werden (falls \fBMFD_ALLOW_SEALING\fP eingesetzt wurde). Auf anderen Dateisystemen werden alle \fBfcntl\fP()\-Aktionen zur Versiegelung \fBEINVAL\fP zurückliefern. .PP 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. .TP \fBF_ADD_SEALS\fP (\fIint\fP; seit Linux 3.17) Fügt die im Bitmasken\-Argument \fIarg\fP übergebenen Siegel zu der Gruppe der Siegel des Inodes, der vom Dateideskriptor \fIdd\fP 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 \fBF_SEAL_SEAL\fP enthält (siehe unten) wird dieser Aufruf mit \fBEPERM\fP abgelehnt. Hinzufügen eines bereits gesetzten Siegels ist eine Nullaktion, falls \fBF_SEAL_SEAL\fP nicht bereits gesetzt ist. Um ein Siegel zu setzen, muss der Dateideskriptor \fIdd\fP schreibbar sein. .TP \fBF_GET_SEALS\fP (\fIvoid\fP; seit Linux 3.17) Liefert (als Funktionsergebnis) die aktuelle Menge der Siegel des durch \fIdd\fP 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 \fIerrno\fP auf \fBEINVAL\fP gesetzt. .PP Die folgenden Versiegelungen sind verfügbar: .TP \fBF_SEAL_SEAL\fP Falls dieses Siegel gesetzt ist, wird jeder zukünftige Aufruf von \fBfcntl\fP() mit \fBF_ADD_SEALS\fP mit dem Fehler \fBEPERM\fP fehlschlagen. Daher verhindert dieses Siegel jede Änderung an der Siegelmenge selbst. Falls die ursprüngliche Siegelmenge einer Datei \fBF_SEAL_SEAL\fP enthält, dann führt dies effektiv dazu, dass die Siegelmenge konstant und gesperrt ist. .TP \fBF_SEAL_SHRINK\fP Falls dieses Siegel gesetzt ist, kann die in Frage kommende Datei nicht verkleinert werden. Dies betrifft \fBopen\fP(2) mit dem Schalter \fBO_TRUNC\fP sowie \fBtruncate\fP(2) und \fBftruncate\fP(2). Diese Aufrufe schlagen mit \fBEPERM\fP fehl, falls Sie versuchen, die in Frage kommende Datei zu verkleinern. Vergrößern der Datei ist weiterhin möglich. .TP \fBF_SEAL_GROW\fP Falls dieses Siegel gesetzt ist, kann die in Frage kommende Datei nicht vergrößert werden. Dies betrifft \fBwrite\fP(2) über das Ende der Datei hinaus, \fBtruncate\fP(2), \fBftruncate\fP(2) und \fBfallocate\fP(2). Diese Aufrufe schlagen mit \fBEPERM\fP 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. .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. .\" Falls dieses Siegel gesetzt ist, können Sie den Inhalt der Datei nicht verändern. Beachten Sie, dass das Verkleinern oder Vergrößern der Größe der Datei weiterhin möglich und erlaubt ist. Daher wird dieses Siegel normalerweise zusammen mit einem der anderen Siegel verwandt. Dieses Siegel betrifft \fBwrite\fP(2) und \fBfallocate\fP(2) (nur in Zusammenhang mit dem Schalter \fBFALLOC_FL_PUNCH_HOLE\fP). Diese Aufrufe werden mit \fBEPERM\fP fehlschlagen, falls dieses Siegel gesetzt ist. Desweiteren wird das Erstellen von gemeinsam benutzten schreibbaren Speicher\-Mappings per \fBmmap\fP(2) auch mit \fBEPERM\fP fehlschlagen. .IP Die Verwendung der Aktion \fBF_ADD_SEALS\fP zum Setzen von \fBF_SEAL_WRITE\fP wird mit \fBEBUSY\fP fehlschlagen, falls irgendeine gemeinsam benutzbares schreibbares Speicher\-Mappings existiert. Derartige Mappings müssen vor dem Hinzufügen dieses Siegels aufgehoben werden. Weiterhin werden alle ausstehenden Schreibvorgänge verworfen, falls irgendwelche asynchronen E/A\-Transaktionen (\fBio_submit\fP(2)) auf die Datei ausstehen. .TP \fBF_SEAL_FUTURE_WRITE\fP (seit Linux 5.1) Die Wirkung dieses Siegels ist ähnlich zu \fBF_SEAL_WRITE\fP, aber der Inhalt der Datei kann weiterhin mittels gemeinsamen schreibbaren Mappings, die vor dem Setzen des Siegels erstellt wurden, verändert werden. Jeder Versuch, ein neues schreibbares Mapping auf der Datei mittels \fBmmap\fP(2) zu erstellen, wird mit \fBEPERM\fP fehlschlagen. Entsprechend wird ein Versuch, in die Datei mit \fBwrite\fP(2) zu schreiben, mit \fBEPERM\fP fehlschlagen. .IP .\" Durch Einsatz dieses Siegels kann ein Prozess einen Speicherpuffer erstellen, den es weiterhin verändern kann und der gleichzeitig von anderen Prozessen »nur lesend« mitgenutzt werden kann. .SS "Datei Lese\-/Schreibehinweise" Der Kernel kann mit Schreib\-Lebenszeithinweisen über die erwartete relative Lebenszeit von Schreibaktionen an einer benannten Inode oder über eine bestimmte offene Dateideskription informiert werden (Siehe \fBopen\fP(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. .PP Eine Anwendung darf die unten angegebenen verschiedenen Hinweisewerte verwenden, um die Schreibaktionen 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. .PP Die folgenden Aktionen können auf den Dateideskriptor \fIdd\fP angewandt werden: .TP \fBF_GET_RW_HINT\fP (\fIuint64_t *\fP; seit Linux 4.13) Liefert den Wert des Lese\-/Schreibhinweises, der der durch \fIdd\fP referenzierten unterliegenden Inode zugeordnet ist. .TP \fBF_SET_RW_HINT\fP (\fIuint64_t *\fP; seit Linux 4.13) Setzt den Wert des Lese\-/Schreibhinweises, der der durch \fIdd\fP referenzierten unterliegenden Inode zugeordnet ist. Dieser Hinweis verbleibt, bis er entweder explizit geändert oder das unterliegende Dateisystem ausgehängt wird. .TP \fBF_GET_FILE_RW_HINT\fP (\fIuint64_t *\fP; seit Linux 4.13) Liefert den Wert des Lese\-/Schreibhinweises, der der durch \fIdd\fP referenzierten offenen Dateideskription zugeordnet ist. .TP \fBF_SET_FILE_RW_HINT\fP (\fIuint64_t *\fP; seit Linux 4.13) Setzt den Wert des Lese\-/Schreibhinweises, der der durch \fIdd\fP referenzierten offenen Dateideskription zugeordnet ist. .PP Falls einer offenen Dateideskription noch kein Lese\-/Schreibhinweis zugeordnet wurde, dann soll der der Inode zugeordnete Wert verwandt werden, falls vorhanden. .PP Die folgenden Lese\-/Schreibhinweise sind seit Linux 4.13 gültig: .TP \fBRWH_WRITE_LIFE_NOT_SET\fP Es wurde kein spezieller Hinweis gesetzt. Dies ist der Vorgabewert. .TP \fBRWH_WRITE_LIFE_NONE\fP Kein spezielle Schreib\-Lebenszeit ist dieser Datei oder diesem Inode zugeordnet. .TP \fBRWH_WRITE_LIFE_SHORT\fP Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen Dateideskriptor geschrieben werden, eine kurze Lebenszeit haben werden. .TP \fBRWH_WRITE_LIFE_MEDIUM\fP Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen Dateideskriptor geschrieben werden, eine längere Lebenszeit als Daten, die mit \fBRWH_WRITE_LIFE_SHORT\fP geschrieben wurden, haben werden. .TP \fBRWH_WRITE_LIFE_LONG\fP Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen Dateideskriptor geschrieben werden, eine längere Lebenszeit als Daten, die mit \fBRWH_WRITE_LIFE_MEDIUM\fP geschrieben wurden, haben werden. .TP \fBRWH_WRITE_LIFE_EXTREME\fP Es wird erwartet, dass Daten, die in diese Inode oder über diesen offenen Dateideskriptor geschrieben werden, eine längere Lebenszeit als Daten, die mit \fBRWH_WRITE_LIFE_LONG\fP geschrieben wurden, haben werden. .PP Alle schreibspezifischen Hinweise sind relativ zueinander und ihnen sollte keine individuelle absolute Bedeutung beigemessen werden. .SH RÜCKGABEWERT Für einen erfolgreichen Aufruf hängt der Rückgabewert von der Aktion ab: .TP \fBF_DUPFD\fP Der neue Dateideskriptor. .TP \fBF_GETFD\fP Wert des File\-Deskriptor\-Schalters. .TP \fBF_GETFL\fP Wert der Dateistatusschalter. .TP \fBF_GETLEASE\fP Art der Ausleihe, die auf dem Dateideskriptor gehalten wird. .TP \fBF_GETOWN\fP Wert des Dateideskriptor\-Eigentümers. .TP \fBF_GETSIG\fP Wert des Signals, wenn Lesen oder Schreiben möglich wird, oder Null für traditionelles \fBSIGIO\fP\-Verhalten. .TP \fBF_GETPIPE_SZ\fP, \fBF_SETPIPE_SZ\fP Die Kapazität der Pipe. .TP \fBF_GET_SEALS\fP Eine Bitmaske, die die Siegel identifiziert, die für den durch \fIdd\fP referenzierten Inode gesetzt wurden. .TP Alle anderen Befehle Null .PP Bei einem Fehler wird \-1 zurückgegeben und \fIerrno\fP wird gesetzt, um den Fehler anzuzeigen. .SH FEHLER .TP \fBEACCES\fP oder \fBEAGAIN\fP Aktion wird durch von anderen Prozessen gehaltene Sperren verhindert. .TP \fBEAGAIN\fP Die Aktion ist verboten, da die Datei durch einen anderen Prozess in den Speicher gemappt wurde. .TP \fBEBADF\fP \fIdd\fP ist kein offener Dateideskriptor. .TP \fBEBADF\fP \fIBef\fP ist \fBF_SETLK\fP oder \fBF_SETLKW\fP und der Öffnungsmodus des Dateideskriptors passt nicht auf die angeforderte Art der Sperre. .TP \fBEBUSY\fP \fIBef\fP ist \fBF_SETPIPE_SZ\fP und die in \fIarg\fP angegebene neue Kapazität der Pipe ist kleiner als die Größe des derzeit zur Speicherung von Daten in der Pipe verwandten Pufferspeichers. .TP \fBEBUSY\fP \fIBef\fP ist \fBF_ADD_SEALS\fP, \fIarg\fP enthält \fBF_SEAL_WRITE\fP und es gibt ein schreibbares gemeinsam benutztes Mapping der Datei, auf das \fIdd\fP verweist. .TP \fBEDEADLK\fP Es wurde erkannt, dass der angegebene Befehl \fBF_SETLKW\fP zu einer Verklemmung führen würde. .TP \fBEFAULT\fP \fIlock\fP befindet sich außerhalb Ihres adressierbaren Adressraums. .TP \fBEINTR\fP \fIBef\fP ist \fBF_SETLKW\fP oder \fBF_OFD_SETLKW\fP und die Aktion wurde durch ein Signal unterbrochen; siehe \fBsignal\fP(7). .TP \fBEINTR\fP \fIBef\fP ist \fBF_GETLK\fP, \fBF_SETLK\fP, \fBF_OFD_GETLK\fP oder \fBF_OFD_SETLK\fP 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. .TP \fBEINVAL\fP Der in \fIBef\fP angegebene Wert wird von diesem Kernel nicht erkannt. .TP \fBEINVAL\fP \fIBef\fP ist \fBF_ADD_SEALS\fP und \fIarg\fP enthält ein nicht erkanntes Versiegelungs\-Bit. .TP \fBEINVAL\fP \fIBef\fP ist \fBF_ADD_SEALS\fP oder \fBF_GET_SEALS\fP und das Dateisystem, das den durch \fIdd\fP referenzierten Inode enthält, unterstützt kein Versiegeln. .TP \fBEINVAL\fP \fIBef\fP ist \fBF_DUPFD\fP und \fIarg\fP ist negativ oder ist größer als der maximal zulässige Wert (siehe die Diskussion von \fBRLIMIT_NOFILE\fP in \fBgetrlimit\fP(2)). .TP \fBEINVAL\fP \fIBef\fP ist \fBF_SETSIG\fP und \fIarg\fP ist keine erlaubbare Signalnummer. .TP \fBEINVAL\fP \fIBef\fP ist \fBF_OFD_SETLK\fP, \fBF_OFD_SETLKW\fP oder \fBF_OFD_GETLK\fP und \fIl_pid\fP wurde nicht als Null angegeben. .TP \fBEMFILE\fP \fIBef\fP ist \fBF_DUPFD\fP und die Beschränkung pro Prozess für die Anzahl offener Dateideskriptoren wurde erreicht. .TP \fBENOLCK\fP Zu viele Segment\-Sperren offen, die Sperr\-Tabelle ist voll oder ein Sperrprotokoll aus der Ferne schlug fehl (z.B. Sperren über NFS). .TP \fBENOTDIR\fP \fBF_NOTIFY\fP wurde in \fIBef\fP angegeben, aber \fIdd\fP zeigt nicht auf ein Verzeichnis. .TP \fBEPERM\fP \fIBef\fP ist \fBF_SETPIPE_SZ\fP und die weiche oder harte Benutzer\-Pipe\-Beschränkung wurde erreicht; siehe \fBpipe\fP(7). .TP \fBEPERM\fP Es wurde versucht, den Schalter \fBO_APPEND\fP auf einer Datei zurückzusetzen, bei der das Attribut »nur anhängen« gesetzt ist. .TP \fBEPERM\fP \fIBef\fP war \fBF_ADD_SEALS\fP aber \fIdd\fP war nicht zum Schreiben offen oder die aktuelle Menge der Siegel der Datei enthält bereits \fBF_SEAL_SEAL\fP. .SH STANDARDS SVr4, 4.3BSD, POSIX.1\-2001. Nur die Aktionen \fBF_DUPFD\fP, \fBF_GETFD\fP, \fBF_SETFD\fP, \fBF_GETFL\fP, \fBF_SETFL\fP, \fBF_GETLK\fP, \fBF_SETLK\fP und \fBF_SETLKW\fP sind in POSIX.1\-2001 spezifiziert. .PP .\" .BR _BSD_SOURCE , .\" or \fBF_GETOWN\fP und \fBF_SETOWN\fP sind in POSIX.1\-2001 spezifiziert. (Um Ihre Definitionen zu erhalten, definieren Sie entweder \fB_XOPEN_SOURCE\fP mit einem Wert größer oder gleich 500 oder definieren Sie \fB_POSIX_C_SOURCE\fP mit einem Wert größer oder gleich 200809L.) .PP \fBF_DUPFD_CLOEXEC\fP ist in POSIX.1\-2001 spezifiziert. (Um diese Definitionen zu erhalten, definieren Sie \fB_POSIX_C_SOURCE\fP mit einem Wert größer oder gleich 200809L oder \fB_XOPEN_SOURCE\fP mit einem Wert größer oder gleich 700.) .PP .\" .PP .\" 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 und \fBF_SETLEASE\fP sind Linux\-spezifisch. (Definieren Sie das Makro \fB_GNU_SOURCE\fP, um diese Definitionen zu erhalten.) .PP \fBF_OFD_SETLK\fP, \fBF_OFD_SETLKW\fP und \fBF_OFD_GETLK\fP sind Linux\-spezifisch (und \fB_GNU_SOURCE\fP 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. .PP .\" FIXME . Once glibc adds support, add a note about FTM requirements \fBF_ADD_SEALS\fP und \fBF_GET_SEALS\fP sind Linux\-spezifisch. .SH ANMERKUNGEN .\" Die Fehler, die von \fBdup2\fP(2) zurückgegeben werden, sind anders als die von \fBF_DUPFD\fP. .SS "Sperrung von Dateien" .\" Der ursprüngliche Systemaufruf \fBfcntl\fP() von Linux war nicht dafür konstruiert, große Dateiversätze (in der Struktur \fIflock\fP) zu handhaben. Konsequenterweise wurde ein Systemaufruf \fBfcntl64\fP() in Linux 2.4 hinzugefügt. Dieser neuere Systemaufruf setzt eine andere Struktur zum Sperren von Dateien ein, \fIflock64\fP, und entsprechende Befehle \fBF_GETLK64\fP, \fBF_SETLK64\fP und \fBF_SETLKW64\fP. Diese Details können allerdings von Anwendungen, die Glibc einsetzen, ignoriert werden, da dessen Wrapperfunktion \fBfcntl\fP() transparent den neueren Systemaufruf einsetzt, wo er verfügbar ist. .SS Datensatzsperren Seit Linux 2.0 gibt es keine Wechselwirkung zwischen den durch \fBflock\fP(2) und \fBfcntl\fP() gesetzten Sperrtypen. .PP .\" 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). Bei einer Reihe von Systemen gibt es in \fIstruct flock\fP weitere Felder wie z.B. \fIl_sysid\fP (zur Identifizierung der Maschine, auf der die Sperre gehalten wird). Es ist klar, dass \fIl_pid\fP alleine nicht sehr nützlich ist, falls der Prozess, der die Sperre hält, auf einer anderen Maschine existiert. Unter Linux wird dieses Feld, auch wenn es auf einigen Architekturen (wie MIPS32) vorhanden ist, nicht verwandt. .PP Der ursprüngliche Systemaufruf \fBfcntl\fP() von Linux war nicht dafür konstruiert, große Dateiversätze (in der Struktur \fIflock\fP) zu handhaben. Konsequenterweise wurde ein Systemaufruf \fBfcntl64\fP() in Linux 2.4 hinzugefügt. Dieser neuere Systemaufruf setzt eine andere Struktur zum Sperren von Dateien ein, \fIflock64\fP, und entsprechende Befehle \fBF_GETLK64\fP, \fBF_SETLK64\fP und \fBF_SETLKW64\fP. Diese Details können allerdings von Anwendungen, die Glibc einsetzen, ignoriert werden, da dessen Wrapperfunktion \fBfcntl\fP() transparent den neueren Systemaufruf einsetzt, wo er verfügbar ist. .SS "Datensatzsperren und 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. .\" 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 \fI/proc/fs/nfsd/nfsv4leasetime\fP, 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. .PP .\" commit ef1820f9be27b6ad158f433ab38002ab8131db4d .\" commit f6de7a39c181dfb8a2c534661a53c73afb3081cd 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 (\fInfs.recover_lost_locks\fP) 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). .SH FEHLER .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 Es ist nicht möglich, \fBF_SETFL\fP zum Ändern des Zustands der Schalter \fBO_DSYNC\fP und \fBO_SYNC\fP zu verwenden. Versuche, den Zustand dieser Schalter zu ändern, werden ohne Meldung ignoriert. .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. Eine Begrenzung der Linux\-Systemaufrufkonventionen auf einigen Architekturen (insbesondere i386) bedeutet, dass, falls eine von \fBF_GETOWN\fP zurückgelieferte (negative) Prozessgruppenkennung 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 \fBfcntl\fP() \-1 sein und \fIerrno\fP wird die (positive) Prozessgruppenkennung enthalten. Die Linux\-spezifische Aktion \fBF_GETOWN_EX\fP vermeidet dieses Problem. Seit Glibc 2.11 versteckt Glibc das Kernelproblem \fBF_GETOWN\fP, indem \fBF_GETOWN\fP mittels \fBF_GETOWN_EX\fP implementiert wird. .SS F_SETOWN .\" Unter Linux 2.4 und älter gibt es einen Fehler, der auftreten kann, wenn ein unprivilegierter Prozess statt einem Aufrufenden \fBF_SETOWN\fP verwendet, um den Eigentümer eines Socket\-Dateideskriptors als Prozess(gruppe) festzulegen. In diesem Fall kann \fBfcntl\fP() \-1 mit \fIerrno\fP auf \fBEPERM\fP 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. .SS "Erkennung von Verklemmungen" .\" Der vom Kernel eingesetzte Algorithmus zur Erkennung von Verklemmungen beim Umgang mit \fBF_SETLKW\fP kann sowohl falsch\-negative (keine Erkennung von Verklemmungen, eine Gruppe von verklemmten Prozessen bleibt unbegrenzt blockiert) als auch falsch\-positive (\fBEDEADLK\fP\-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 \fBCLONE_FILES\fP von \fBclone\fP(2) Sperren setzen, die (dem Kernel) als im Konflikt stehend erscheinen. .SS Pflichtsperren .\" http://marc.info/?l=linux-kernel&m=119013491707153&w=2 .\" .\" Reconfirmed by Jeff Layton .\" From: Jeff Layton 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 Die Linux\-Implementierung von Pflichtsperren ist Gegenstand von Ressourcenwettläufen, die sie unzuverlässig machen: Ein \fBwrite\fP(2)\-Aufruf, der sich mit einer Sperre überschneidet, kann Daten verändern, nachdem die Pflichtsperre erlangt wurde. Ein \fBread\fP(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 \fBmmap\fP(2). Daher ist es nicht zu empfehlen, sich auf Pflichtsperren zu verlassen. .SH "SIEHE AUCH" \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) .PP \fIlocks.txt\fP, \fImandatory\-locking.txt\fP und \fIdnotify.txt\fP in dem Linux\-Kernelquelldateiverzeichnis \fIDocumentation/filesystems/\fP. (Bei älteren Kerneln befinden sich diese Dateien direkt unter dem Verzeichnis \fIDocumentation/\fP und \fImandatory\-locking.txt\fP heißt \fImandatory.txt\fP.) .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Martin Schulze , Chris Leick , Helge Kreutzmann und Mario Blättermann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .