flock - wendet empfohlene Sperren auf eine offene Datei an oder entfernt sie
Standard-C-Bibliothek (
libc,
-lc)
#include <sys/file.h>
int flock(int dd, int Aktion);
Wendet empfohlene Sperren auf eine offene, durch
dd angegebene Datei an
oder entfernt sie. Das Argument
Aktion ist eines der folgenden:
- LOCK_SH
- Richtet eine gemeinsame Sperre ein. Mehrere Prozesse
können eine Datei zur selben Zeit sperren.
- LOCK_EX
- Richtet eine exklusive Sperre ein. Nur ein Prozess kann zu
einer Zeit eine Datei sperren.
- LOCK_UN
- entfernt eine von diesem Prozess gehaltene Sperre.
Ein Aufruf von
flock() kann blockieren, wenn von einem anderen Prozess
eine inkompatible Sperre gehalten wird. Um eine nichtblockierende Anfrage zu
machen, verbinden Sie
LOCK_NB (mittels ODER) mit irgendeiner der obigen
Aktionen.
Eine einzelne Datei kann nicht gleichzeitig gemeinsame und alleinige Sperren
haben.
Mit
flock() erstellte Sperren sind mit einem offenen Eintrag in der
Dateitabelle verbunden (siehe
open(2)). Dies bedeutet, dass Kopien der
Dateideskriptoren (erzeugt durch zum Beispiel
fork(2) oder
dup(2)) sich auf die gleiche Sperre beziehen. Diese Sperre kann von
jedem dieser Dateideskriptoren modifiziert oder freigegeben werden. Weiterhin
wird die Sperre entweder durch eine explizite
LOCK_UN-Aktion auf jedem
dieser doppelten Dateideskriptoren freigegeben oder wenn alle derartigen
Dateideskriptoren geschlossen wurden.
Falls ein Prozess
open(2) (oder etwas Ähnliches) verwendet, um
mehrere Datedeskriptoren für dieselbe Datei zu erhalten, werden diese
Dateideskriptoren von
flock() unabhängig behandelt. Ein Versuch,
die Datei mit einem dieser Dateideskriptoren zu sperren kann durch eine Sperre
verwehrt werden, die der aufrufende Prozess bereits für einen anderen
Dateideskriptor eingerichtet hat.
Ein Prozess darf nur einen Typ vor Sperre (gemeinsam oder exklusiv) auf eine
Datei halten. Nachfolgende Aufrufe von
flock() für eine bereits
gesperrte Datei wird eine bestehende Sperre zum neuen Sperrmodus
ändern.
Von
flock() angelegte Sperren bleiben über einen Aufruf von
execve(2) erhalten.
Eine Datei kann unabhängig vom Modus, mit dem sie geöffnet wurde,
mit einer gemeinsamen oder exklusiven Sperre versehen werden.
Bei Erfolg wird Null zurückgegeben. Bei einem Fehler wird -1
zurückgegeben und
errno gesetzt, um den Fehler anzuzeigen.
- EBADF
-
dd ist kein Deskriptor für eine
geöffnete Datei.
- EINTR
- Während des Wartens auf die Sperre wurde der Aufruf
durch ein von einem Handler abgefangenes Signal unterbrochen; siehe
signal(7).
- EINVAL
-
Aktion ist ungültig.
- ENOLCK
- Der Kernel hatte keinen Speicher mehr für das
Anlegen von Sperrdatensätzen (lock records).
- EWOULDBLOCK
- Die Datei ist gesperrt und der Schalter LOCK_NB
wurde gewählt.
4.4BSD (der Systemaufruf
flock() erschien erstmals in 4.2BSD). Eine
Version von
flock(), möglicherweise in Form von
fcntl(2)
realisiert, ist auf den meisten UNIX-Systemen vorhanden.
Seit Linux 2.0 wird
flock() als eigener Systemaufruf realisiert anstatt
in der GNU-C-Bibliothek als Aufruf von
fcntl(2) emuliert zu werden. Es
gibt keine Wechselwirkung zwischen den Arten von Sperren, die von
flock() und
fcntl(2) angelegt wurden. Außerdem erkennt
flock() keine Deadlocks. (Beachten Sie, dass auf einigen modernen
BSD-Systemen durch
flock() und
fcntl(2) erzeugte Sperren
miteinander interagieren.)
flock() setzt nur empfehlende Sperren, bei geeigneten Berechtigungen
für eine Datei kann ein Prozess den Einsatz von
flock()
ignorieren und E/A auf die Datei durchführen.
Die von
flock() und
fcntl(2) eingerichteten Sperren haben
unterschiedliche Semantik in Bezug auf durch
fork(2) erzeugte Prozesse
und
dup(2). Auf Systemen, die
flock () mit
fcntl(2)
implementieren, wird die Semantik von
flock() anders sein als die in
dieser Handbuchseite beschriebene.
Die Umwandlung einer Sperre (von gemeinsam zu exklusiv oder umgekehrt) ist nicht
garantiert atomar: zuerst wird die bestehende Sperre entfernt und dann eine
neue Sperre errichtet. Zwischen diesen beiden Schritten kann eine anstehende
Sperranforderung von einem anderen Prozess gewährt werden, mit dem
Ergebnis, dass die Umwandlung entweder blockiert oder, wenn
LOCK_NB
angegeben wurde, fehlschlägt. (Dies ist die ursprüngliche
BSD-Verhalten und tritt bei vielen anderen Implementierungen auf.)
In Linux bis 2.6.11 sperrte
flock() keine Dateien über NFS (d.h.
der Gültigkeitsbereich von Sperren beschränkte sich auf das
lokale System). Stattdessen konnte
fcntl(2) für
Byte-Bereichssperren, die über NFS funktionieren, verwandt werden,
sofern eine ausreichend neue Version von Linux und ein Server, der Sperren
unterstützt, eingesetzt wurden.
Seit Linux 2.6.12 unterstützen NFS-Clients
flock(), indem sie sie
mit
fcntl(2)-Byte-Bereichssperren über die gesamte Datei
emulieren. Das bedeutet, dass
fcntl(2)- und
flock()-Sperren
über NFS interagieren. Dies bedeutet auch, das zum Setzen einer
exklusive Sperre die Datei zum Schreiben geöffnet sein muss.
Seit Linux 2.6.37 unterstützt der Kernel einen
Kompatibilitätsmodus, der
flock()-Sperren (und auch
fcntl(2)-Byte-Bereichssperren) als lokal behandelt; siehe die
Diskussion der Option
local_lock in
nfs(5).
In Linux bis 5.4 wird
flock() nicht über SMB weitergeleitet. Eine
Datei mit solchen Sperren wird auf fernen Clients nicht gesperrt erscheinen.
Seit Linux 5.5 werden
flock()-Sperren mit SMB-Byte-Bereichssperren
über die gesamte Datei emuliert. Ähnlich wie bei NFS bedeutet
dies, dass
fcntl(2)- und
flock()-Sperren miteinander
wechselwirken. Eine anderer wichtiger Seiteneffekt ist, dass die Sperren nicht
mehr empfohlene sind: jede E/A auf einer gesperrten Datei wird immer mit
EACCES fehlschlagen, wenn sie von einem separaten Dateideskriptor aus
erfolgt. Dieser Unterschied stammt von dem Design der Sperren in dem
SMB-Protokoll, das die Semantik verpflichtender Sperren bereitstellt.
Die Semantik ferner und verpflichtender Sperren können sich mit dem
SMB-Protokoll, den Einhängeoptionen und dem Server-Typ ändern.
Siehe
mount.cifs(8) für zusätzliche Informationen.
flock(1),
close(2),
dup(2),
execve(2),
fcntl(2),
fork(2),
open(2),
lockf(3),
lslocks(8)
Documentation/filesystems/locks.txt im Linux-Kernelquellbaum (
Documentation/locks.txt bei älteren Kerneln).
Die deutsche Übersetzung dieser Handbuchseite wurde von Dennis Stampfer
<
[email protected]>, Martin Eberhard Schauer
<
[email protected]>, Mario Blättermann
<
[email protected]> und Helge Kreutzmann
<
[email protected]> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU
General Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
Sie bitte eine E-Mail an die
Mailingliste
der Übersetzer