getrlent(3N) getrlent(3N)
NAME
getrlent, setrlent, endrlent, getrlclient, getrlfile - Dateisperren
von NFS-Clients holen
SYNTAX
#include <rpc/types.h>
#include <nfs/nfs.h>
#include <nfs/nfssys.h>
struct remotelock *getrlent(boolt fhonly);
struct remotelock *getrlclient(boolt fhonly);
struct remotelock *getrlfile(char *fname);
void setrlent(void);
void endrlent(void);
BESCHREIBUNG
Beim ersten Aufruf von getrlent, getrlclient oder getrlfile werden
alle Dateisperren von NFS-Clients in einen Puffer gelesen. getrlent,
getrlclient und getrlfile liefern einen Zeiger auf die erste Sperre
bzw. die erste Sperre für den gegebenen Client bzw. die erste Sperre
für die gegebene Datei. Nachfolgende Aufrufe dieser Funktionen liefern
jeweils die nächste Sperre für das gegebene Kriterium (keines, Client
oder Datei). Ist die letzte Sperre erreicht, wird beim nächsten Aufruf
ein NULL-Zeiger zurückgegeben.
Achtung: getrlent, getrlclient und getrlfile benutzen die "aktuelle"
Sperre gemeinsam (= die letzte, die von einer dieser Funktionen geholt
wurde). Es ist also Vorsicht geboten, wenn zum Holen von Sperren in
einem einzigen Durchlauf durch die Sperrentabelle verschiedene Funk-
tionen benutzt werden.
Die Struktur remotelock ist in <nfs/nfssys.h> definiert:
struct remotelock {
union {
struct { /* nur bei gesetzter Sperre */
fhandlet fh; /* "Handle" der gesperrten Datei */
char *fname; /* Name der gesperrten Datei */
} ufile;
struct { /* nur bei blockierter Sperre */
pidt bpid; /* PID des blockierenden Prozesses */
char *bname; /* Name des blockierenden Clients */
} ublk;
} rlu;
char *rlclient; /* Name des Clients */
pidt rlpid; /* PID des Client-Prozesses */
Seite 1 Reliant UNIX 5.44 Gedruckt 11/98
getrlent(3N) getrlent(3N)
short rltype; /* Typ der Sperre (exklusiv/mehrfach) */
short rlstate; /* Status der Sperre (gesetzt/blockiert) */
offt rlstart; /* Startposition der Sperre */
offt rllen; /* Länge der Sperre */
};
rlstate bezeichnet den Status der Sperre. Sie kann gesetzt
(GRANTEDLOCK) oder durch eine andere Sperre blockiert sein
(BLOCKEDLOCK). Eine Sperre im Status GRANTEDLOCK kann gleichzeitig
eine andere Sperre blockieren. Im rlstate-Feld ist dann zusätzlich
das Bit BLOCKINGLOCK gesetzt.
rlu.ufile bezeichnet die Datei, für die die Sperre gesetzt wurde
(vorausgesetzt, sie hat den Status GRANTEDLOCK). Die Datei wird durch
ein 32 Byte großes Dateikennzeichen, das "Dateihandle" identifiziert
(rlu.ufile.fh) und - optional - durch ihren absoluten Pfadnamen
(rlu.ufile.fname).
Der Pfadname wird nur geliefert, wenn das fhonly-Flag im Aufruf von
getrlent oder getrlclient FALSE gesetzt ist. (Für getrlfile wird der
Pfadname als Aufrufparameter ohnehin angegeben.)
Die Umwandlung eines Dateihandles in einen Pfadnamen ist sehr zeitauf-
wendig und sollte soweit möglich vermieden werden. Wenn fhonly auf
TRUE gesetzt ist, unterbleibt die Umwandlung, und im Feld
rlu.ufile.fname wird NULL zurückgegeben.
Bei einer Sperre im Status BLOCKEDLOCK identifiziert rlu.ublk den
Blockierer durch die Prozess-ID (rlu.ublk.bpid) und den Namen des
Clients (rlu.ublk.bname), von dem die blockierende Sperre abgesetzt
wurde.
rlclient enthält den Namen des Clients, der die Sperre angefordert
hat.
rlpid enthält die Prozeß-ID des Prozesses, der die Sperre angefordert
hat.
rltype enthält den Typ der Sperre gemäß <sys/fcntl.h>.
rlstart und rllen enthalten die Startposition und Länge des gesperr-
ten Bereichs.
setrlent setzt die "aktuelle" Sperre auf die erste im Puffer.
endrlent markiert den Pufferinhalt als ungültig. Der nächste Aufruf
von getrlent, getrlclient oder getrlfile verhält sich dann wie der
erste Aufruf, d. h. die Sperrentabelle wird erneut in den Puffer gele-
sen.
SIEHE AUCH
nfslockadm(1M), removerlock(3N).
Seite 2 Reliant UNIX 5.44 Gedruckt 11/98