Provided by: manpages-de-dev_4.21.0-2_all bug

BEZEICHNUNG

       fcntl - Dateideskriptoren manipulieren

BIBLIOTHEK

       Standard-C-Bibliothek (libc, -lc)

ÜBERSICHT

       #include <fcntl.h>

       int fcntl(int dd, int Bef,  /* arg */ );

BESCHREIBUNG

       fcntl()  führt  eine  der  unten beschriebenen Aktionen auf dem offenen Dateideskriptor dd
       aus. Die Aktion wird durch Bef festgelegt.

       fcntl() kann ein optionales drittes Argument akzeptieren.  Ob  dieses  Argument  notwendig
       ist,  ergibt  sich  durch  Bef.  Der  benötigte  Argumenttyp  wird nach jedem Bef-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 Bef 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 dd 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 angegebenen 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    angegebenen    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),  dem  aktuellen
       Dateiversatz (falls l_whence SEEK_CUR  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 2.4.21 und 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  dd zum Lesen offen sein. Um eine Schreibsperre zu
       setzen, muss dd 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.  In  Linux  5.15  und  neuer  wird  diese  Funktionalität  nicht   mehr
       unterstützt.

       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 Prozess- oder Prozessgruppenkennung zurück, die
              derzeit  SIGIO-  und  SIGURG-Signale  für Ereignisse auf Dateideskriptor dd 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 dd erhalten wird. Der Zielprozess  oder  die
              Zielprozessgruppe  wird  in  arg 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. arg wird als getpid(2) angegeben).

              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 dd 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 Linux 2.6.x bis einschließlich Linux 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 deaktiviert 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  dd 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 dd 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 der Ausleih-Brech-Timer 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) angegeben 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 dd referenzierte
              Verzeichnis oder eine der darin enthaltenen Dateien geändert wird. Die  Ereignisse,
              für  die  benachrichtigt  wird, werden in arg angegeben. 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 Linux
              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 dd 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.

              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.

       F_GETPIPE_SZ (void; seit Linux 2.6.35)
              Liefert  (als Ergebnis der Funktion) die Kapazität der durch dd 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 dd 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 dd schreibbar sein.

       F_GET_SEALS (void; seit Linux 3.17)
              Liefert  (als  Funktionsergebnis)  die  aktuelle  Menge  der  Siegel  des  durch dd
              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
              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 write(2) und fallocate(2) (nur
              in Zusammenhang mit dem Schalter FALLOC_FL_PUNCH_HOLE). Diese  Aufrufe  werden  mit
              EPERM fehlschlagen, falls dieses Siegel gesetzt ist. Desweiteren wird das Erstellen
              von gemeinsam benutzten schreibbaren Speicher-Mappings per mmap(2) auch  mit  EPERM
              fehlschlagen.

              Die  Verwendung  der  Aktion F_ADD_SEALS zum Setzen von F_SEAL_WRITE wird mit EBUSY
              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 (io_submit(2)) auf die Datei ausstehen.

       F_SEAL_FUTURE_WRITE (seit Linux 5.1)
              Die  Wirkung  dieses Siegels ist ähnlich zu F_SEAL_WRITE, 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 mmap(2) zu erstellen, wird  mit  EPERM  fehlschlagen.
              Entsprechend  wird  ein  Versuch, in die Datei mit write(2) zu schreiben, mit EPERM
              fehlschlagen.

              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.

   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 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 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.

       Die folgenden Aktionen können auf den Dateideskriptor dd angewandt werden:

       F_GET_RW_HINT (uint64_t *; seit Linux 4.13)
              Liefert  den  Wert  des  Lese-/Schreibhinweises,  der  der  durch dd referenzierten
              unterliegenden Inode zugeordnet ist.

       F_SET_RW_HINT (uint64_t *; seit Linux 4.13)
              Setzt  den  Wert  des  Lese-/Schreibhinweises,  der  der  durch  dd  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  dd  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 dd 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

       Für einen erfolgreichen Aufruf hängt der Rückgabewert von der Aktion ab:

       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  dd  referenzierten
              Inode gesetzt wurden.

       Alle anderen Befehle
              Null

       Bei einem Fehler wird -1 zurückgegeben und errno wird gesetzt, um den Fehler anzuzeigen.

FEHLER

       EACCES oder EAGAIN
              Aktion wird durch von anderen Prozessen gehaltene Sperren verhindert.

       EAGAIN Die  Aktion  ist verboten, da die Datei durch einen anderen Prozess in den Speicher
              gemappt wurde.

       EBADF  dd ist kein offener Dateideskriptor.

       EBADF  Bef ist F_SETLK oder F_SETLKW und  der  Öffnungsmodus  des  Dateideskriptors  passt
              nicht auf die angeforderte Art der Sperre.

       EBUSY  Bef  ist F_SETPIPE_SZ und die in arg angegebene neue Kapazität der Pipe ist kleiner
              als die Größe des  derzeit  zur  Speicherung  von  Daten  in  der  Pipe  verwandten
              Pufferspeichers.

       EBUSY  Bef  ist  F_ADD_SEALS,  arg  enthält  F_SEAL_WRITE  und  es  gibt  ein schreibbares
              gemeinsam benutztes Mapping der Datei, auf das dd verweist.

       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  Bef  ist  F_SETLKW  oder  F_OFD_SETLKW  und  die  Aktion  wurde  durch  ein  Signal
              unterbrochen; siehe signal(7).

       EINTR  Bef 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 Bef angegebene Wert wird von diesem Kernel nicht erkannt.

       EINVAL Bef ist F_ADD_SEALS und arg enthält ein nicht erkanntes Versiegelungs-Bit.

       EINVAL Bef  ist  F_ADD_SEALS  oder  F_GET_SEALS  und  das  Dateisystem,  das  den durch dd
              referenzierten Inode enthält, unterstützt kein Versiegeln.

       EINVAL Bef 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 Bef ist F_SETSIG und arg ist keine erlaubbare Signalnummer.

       EINVAL Bef  ist  F_OFD_SETLK, F_OFD_SETLKW oder F_OFD_GETLK und l_pid wurde nicht als Null
              angegeben.

       EMFILE Bef  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 Bef angegeben, aber dd zeigt nicht auf ein Verzeichnis.

       EPERM  Bef 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  Bef war F_ADD_SEALS aber dd war nicht zum Schreiben offen oder die  aktuelle  Menge
              der Siegel der Datei enthält bereits F_SEAL_SEAL.

STANDARDS

       SVr4,  4.3BSD, POSIX.1-2001. Nur die Aktionen 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 Linux 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 (zur
       Identifizierung der Maschine, auf der die Sperre gehalten wird). 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. Unter Linux wird dieses Feld, auch wenn es auf  einigen  Architekturen
       (wie MIPS32) vorhanden ist, nicht verwandt.

       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)
       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 fcntl() -1
       sein und errno wird die (positive) Prozessgruppenkennung enthalten. Die  Linux-spezifische
       Aktion  F_GETOWN_EX  vermeidet  dieses  Problem.  Seit  Glibc  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.)

ÜBERSETZUNG

       Die    deutsche    Übersetzung    dieser    Handbuchseite   wurde   von   Martin   Schulze
       <joey@infodrom.org>,    Chris     Leick     <c.leick@vollbio.de>,     Helge     Kreutzmann
       <debian@helgefjell.de> und Mario Blättermann <mario.blaettermann@gmail.com> erstellt.

       Diese  Übersetzung  ist  Freie  Dokumentation;  lesen  Sie  die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.