Zum Hauptinhalt springen

2. RPC-Informationen (RPC Information)

2.1 Authentifizierung (Authentication)​

Der NFS-Dienst verwendet AUTH_NONE in der NULL-Prozedur. AUTH_UNIX, AUTH_DES oder AUTH_KERB werden für alle anderen Prozeduren verwendet. Andere Authentifizierungstypen können in Zukunft unterstützt werden.

2.2 Konstanten (Constants)​

Dies sind die RPC-Konstanten, die zum Aufruf des NFS Version 3 Dienstes benötigt werden. Sie werden in Dezimalform angegeben.

PROGRAM  100003
VERSION  3

2.3 Transportadresse (Transport address)​

Das NFS-Protokoll wird normalerweise über die TCP- und UDP-Protokolle unterstützt. Es verwendet Port 2049, denselben wie das NFS Version 2 Protokoll.

2.4 Größen (Sizes)​

Dies sind die Größen in dezimalen Bytes verschiedener XDR-Strukturen, die im NFS Version 3 Protokoll verwendet werden:

NFS3_FHSIZE 64

  • Die maximale Größe in Bytes des opaken Datei-Handles.

NFS3_COOKIEVERFSIZE 8

  • Die Größe in Bytes des opaken Cookie-Verifizierers, der von READDIR und READDIRPLUS übergeben wird.

NFS3_CREATEVERFSIZE 8

  • Die Größe in Bytes des opaken Verifizierers, der für exklusives CREATE verwendet wird.

NFS3_WRITEVERFSIZE 8

  • Die Größe in Bytes des opaken Verifizierers, der für asynchrones WRITE verwendet wird.

2.5 Grundlegende Datentypen (Basic Data Types)​

Die folgenden XDR-Definitionen sind grundlegende Definitionen, die in anderen Strukturen verwendet werden.

uint64

typedef unsigned hyper uint64;

int64

typedef hyper int64;

uint32

typedef unsigned long uint32;

int32

typedef long int32;

filename3

typedef string filename3<>;

nfspath3

typedef string nfspath3<>;

fileid3

typedef uint64 fileid3;

cookie3

typedef uint64 cookie3;

cookieverf3

typedef opaque cookieverf3[NFS3_COOKIEVERFSIZE];

createverf3

typedef opaque createverf3[NFS3_CREATEVERFSIZE];

writeverf3

typedef opaque writeverf3[NFS3_WRITEVERFSIZE];

uid3

typedef uint32 uid3;

gid3

typedef uint32 gid3;

size3

typedef uint64 size3;

offset3

typedef uint64 offset3;

mode3

typedef uint32 mode3;

count3

typedef uint32 count3;

nfsstat3

enum nfsstat3 {
   NFS3_OK             = 0,
   NFS3ERR_PERM        = 1,
   NFS3ERR_NOENT       = 2,
   NFS3ERR_IO          = 5,
   NFS3ERR_NXIO        = 6,
   NFS3ERR_ACCES       = 13,
   NFS3ERR_EXIST       = 17,
   NFS3ERR_XDEV        = 18,
   NFS3ERR_NODEV       = 19,
   NFS3ERR_NOTDIR      = 20,
   NFS3ERR_ISDIR       = 21,
   NFS3ERR_INVAL       = 22,
   NFS3ERR_FBIG        = 27,
   NFS3ERR_NOSPC       = 28,
   NFS3ERR_ROFS        = 30,
   NFS3ERR_MLINK       = 31,
   NFS3ERR_NAMETOOLONG = 63,
   NFS3ERR_NOTEMPTY    = 66,
   NFS3ERR_DQUOT       = 69,
   NFS3ERR_STALE       = 70,
   NFS3ERR_REMOTE      = 71,
   NFS3ERR_BADHANDLE   = 10001,
   NFS3ERR_NOT_SYNC    = 10002,
   NFS3ERR_BAD_COOKIE  = 10003,
   NFS3ERR_NOTSUPP     = 10004,
   NFS3ERR_TOOSMALL    = 10005,
   NFS3ERR_SERVERFAULT = 10006,
   NFS3ERR_BADTYPE     = 10007,
   NFS3ERR_JUKEBOX     = 10008
};

Der Typ nfsstat3 wird mit den Ergebnissen jeder Prozedur zurückgegeben, außer bei der NULL-Prozedur. Ein Wert von NFS3_OK zeigt an, dass der Aufruf erfolgreich abgeschlossen wurde. Jeder andere Wert zeigt an, dass beim Aufruf ein Fehler aufgetreten ist, der durch den Fehlercode identifiziert wird. Beachten Sie, dass die präzise numerische Kodierung befolgt werden muss. Keine anderen Werte dürfen von einem Server zurückgegeben werden. Server werden erwartet, eine bestmögliche Zuordnung von Fehlerbedingungen zu der definierten Menge von Fehlercodes vorzunehmen. Darüber hinaus werden in dieser Spezifikation keine Fehlerpriorisierungen angegeben. Fehlerpriorisierungen bestimmen den Fehlerwert, der zurückgegeben werden soll, wenn mehr als ein Fehler in einer gegebenen Situation zutrifft. Die Fehlerpriorisierung wird durch die individuelle Server-Implementierung bestimmt. Wenn der Client spezifische Fehlerpriorisierungen benötigt, sollte er selbst nach den spezifischen Fehlern suchen.

2.6 Definierte Fehlernummern (Defined Error Numbers)​

Eine Beschreibung jedes definierten Fehlers folgt:

NFS3_OK

  • Zeigt an, dass der Aufruf erfolgreich abgeschlossen wurde.

NFS3ERR_PERM

  • Nicht Eigentümer. Die Operation wurde nicht erlaubt, weil der Aufrufer entweder kein privilegierter Benutzer (root) ist oder nicht der Eigentümer des Ziels der Operation ist.

NFS3ERR_NOENT

  • Datei oder Verzeichnis nicht vorhanden. Der angegebene Datei- oder Verzeichnisname existiert nicht.

NFS3ERR_IO

  • I/O-Fehler. Ein harter Fehler (zum Beispiel ein Festplattenfehler) ist während der Verarbeitung der angeforderten Operation aufgetreten.

NFS3ERR_NXIO

  • I/O-Fehler. Kein solches Gerät oder Adresse.

NFS3ERR_ACCES

  • Zugriff verweigert. Der Aufrufer hat nicht die korrekte Berechtigung, um die angeforderte Operation auszuführen. Vergleichen Sie dies mit NFS3ERR_PERM, das sich auf Eigentümer- oder privilegierte Benutzerberechtigungsfehler beschränkt.

NFS3ERR_EXIST

  • Datei existiert. Die angegebene Datei existiert bereits.

NFS3ERR_XDEV

  • Versuch, einen geräteübergreifenden harten Link zu erstellen.

NFS3ERR_NODEV

  • Kein solches Gerät.

NFS3ERR_NOTDIR

  • Kein Verzeichnis. Der Aufrufer hat ein Nicht-Verzeichnis in einer Verzeichnisoperation angegeben.

NFS3ERR_ISDIR

  • Ist ein Verzeichnis. Der Aufrufer hat ein Verzeichnis in einer Nicht-Verzeichnisoperation angegeben.

NFS3ERR_INVAL

  • Ungültiges Argument oder nicht unterstütztes Argument für eine Operation. Zwei Beispiele sind der Versuch eines READLINK auf einem anderen Objekt als einem symbolischen Link oder der Versuch eines SETATTR eines Zeitfeldes auf einem Server, der diese Operation nicht unterstützt.

NFS3ERR_FBIG

  • Datei zu groß. Die Operation hätte dazu geführt, dass eine Datei über die Grenze des Servers hinaus wächst.

NFS3ERR_NOSPC

  • Kein Speicherplatz mehr auf dem Gerät. Die Operation hätte dazu geführt, dass das Dateisystem des Servers seine Grenze überschreitet.

NFS3ERR_ROFS

  • Nur-Lese-Dateisystem. Eine modifizierende Operation wurde auf einem Nur-Lese-Dateisystem versucht.

NFS3ERR_MLINK

  • Zu viele harte Links.

NFS3ERR_NAMETOOLONG

  • Der Dateiname in einer Operation war zu lang.

NFS3ERR_NOTEMPTY

  • Es wurde versucht, ein nicht leeres Verzeichnis zu entfernen.

NFS3ERR_DQUOT

  • Ressourcen (Quota) Hardlimit überschritten. Das Ressourcenlimit des Benutzers auf dem Server wurde überschritten.

NFS3ERR_STALE

  • Ungültiges Datei-Handle. Das in den Argumenten angegebene Datei-Handle war ungültig. Die durch dieses Datei-Handle referenzierte Datei existiert nicht mehr oder der Zugriff darauf wurde widerrufen.

NFS3ERR_REMOTE

  • Zu viele Ebenen von Remote im Pfad. Das in den Argumenten angegebene Datei-Handle bezog sich auf eine Datei auf einem nicht-lokalen Dateisystem auf dem Server.

NFS3ERR_BADHANDLE

  • Illegales NFS-Datei-Handle. Das Datei-Handle hat interne Konsistenzprüfungen nicht bestanden.

NFS3ERR_NOT_SYNC

  • Update-Synchronisationskonflikt wurde während einer SETATTR-Operation erkannt.

NFS3ERR_BAD_COOKIE

  • READDIR- oder READDIRPLUS-Cookie ist veraltet.

NFS3ERR_NOTSUPP

  • Operation wird nicht unterstützt.

NFS3ERR_TOOSMALL

  • Puffer oder Anfrage ist zu klein.

NFS3ERR_SERVERFAULT

  • Ein Fehler ist auf dem Server aufgetreten, der auf keinen der legalen NFS Version 3 Protokollfehlerwerte abbildet. Der Client sollte dies in einen geeigneten Fehler übersetzen. UNIX-Clients können wählen, dies in EIO zu übersetzen.

NFS3ERR_BADTYPE

  • Es wurde versucht, ein Objekt eines vom Server nicht unterstützten Typs zu erstellen.

NFS3ERR_JUKEBOX

  • Der Server hat die Anfrage initiiert, konnte sie jedoch nicht rechtzeitig abschließen. Der Client sollte warten und dann die Anfrage mit einer neuen RPC-Transaktions-ID wiederholen. Zum Beispiel sollte dieser Fehler von einem Server zurückgegeben werden, der hierarchischen Speicher unterstützt und eine Anfrage zur Verarbeitung einer migrierten Datei erhält. In diesem Fall sollte der Server den Immigrationsprozess starten und dem Client mit diesem Fehler antworten.

ftype3

enum ftype3 {
   NF3REG    = 1,
   NF3DIR    = 2,
   NF3BLK    = 3,
   NF3CHR    = 4,
   NF3LNK    = 5,
   NF3SOCK   = 6,
   NF3FIFO   = 7
};

Die Aufzählung ftype3 gibt den Typ einer Datei an. Der Typ NF3REG ist eine reguläre Datei, NF3DIR ist ein Verzeichnis, NF3BLK ist eine spezielle Block-Gerätedatei, NF3CHR ist eine spezielle Zeichen-Gerätedatei, NF3LNK ist ein symbolischer Link, NF3SOCK ist ein Socket und NF3FIFO ist eine benannte Pipe. Beachten Sie, dass die präzise Enum-Kodierung befolgt werden muss.

specdata3

struct specdata3 {
     uint32     specdata1;
     uint32     specdata2;
};

Die Interpretation der beiden Wörter hängt vom Typ des Dateisystemobjekts ab. Für eine spezielle Block- (NF3BLK) oder Zeichen-Datei (NF3CHR) sind specdata1 und specdata2 jeweils die Major- und Minor-Gerätenummern. (Dies ist offensichtlich eine UNIX-spezifische Interpretation.) Für alle anderen Dateitypen sollten diese beiden Elemente entweder auf 0 gesetzt werden oder die Werte sollten zwischen Client und Server vereinbart werden. Wenn Client und Server sich nicht über die Werte einig sind, sollte der Client diese Felder so behandeln, als ob sie auf 0 gesetzt wären. Dieses Datenfeld wird als Teil der fattr3-Struktur zurückgegeben und ist daher aus allen Antworten verfügbar, die Attribute zurückgeben. Da diese Felder für Objekte, die keine Geräte sind, anderweitig ungenutzt sind, können Out-of-Band-Informationen vom Server an den Client weitergegeben werden. Jedoch müssen sich sowohl Server als auch Client über die übergebenen Werte einig sein.

nfs_fh3

struct nfs_fh3 {
   opaque       data<NFS3_FHSIZE>;
};

Das nfs_fh3 ist das opake Objekt mit variabler Länge, das vom Server bei LOOKUP-, CREATE-, SYMLINK-, MKNOD-, LINK- oder READDIRPLUS-Operationen zurückgegeben wird und vom Client bei nachfolgenden Operationen verwendet wird, um auf die Datei zu verweisen. Das Datei-Handle enthält alle Informationen, die der Server benötigt, um eine einzelne Datei zu unterscheiden. Für den Client ist das Datei-Handle opak. Der Client speichert Datei-Handles zur Verwendung in einer späteren Anfrage und kann zwei Datei-Handles vom selben Server auf Gleichheit vergleichen, indem er einen Byte-für-Byte-Vergleich durchführt, kann aber den Inhalt der Datei-Handles nicht anderweitig interpretieren. Wenn zwei Datei-Handles vom selben Server gleich sind, müssen sie sich auf dieselbe Datei beziehen, aber wenn sie nicht gleich sind, können keine Schlüsse gezogen werden. Server sollten versuchen, eine Eins-zu-eins-Korrespondenz zwischen Datei-Handles und Dateien aufrechtzuerhalten, aber dies ist nicht erforderlich. Clients sollten Datei-Handle-Vergleiche nur zur Verbesserung der Leistung verwenden, nicht für korrektes Verhalten.

Server können den durch ein Datei-Handle bereitgestellten Zugriff jederzeit widerrufen. Wenn das in einem Aufruf übergebene Datei-Handle sich auf ein Dateisystemobjekt bezieht, das auf dem Server nicht mehr existiert, oder wenn der Zugriff für dieses Datei-Handle widerrufen wurde, sollte der Fehler NFS3ERR_STALE zurückgegeben werden.

nfstime3

struct nfstime3 {
   uint32   seconds;
   uint32   nseconds;
};

Die nfstime3-Struktur gibt die Anzahl der Sekunden und Nanosekunden seit Mitternacht, 1. Januar 1970 Greenwich Mean Time an. Sie wird verwendet, um Zeit- und Datumsinformationen zu übergeben. Die mit Dateien verbundenen Zeiten sind alle Serverzeiten, außer im Fall einer SETATTR-Operation, bei der der Client die Dateizeit explizit setzen kann. Ein Server konvertiert bei der Verarbeitung von Zeitwerten zur und von der Ortszeit und bewahrt dabei so viel Genauigkeit wie möglich. Wenn die Präzision der für eine Datei gespeicherten Zeitstempel geringer ist als die vom NFS Version 3 Protokoll definierte, kann ein Präzisionsverlust auftreten. Ein ergänzendes Zeitwartungsprotokoll wird empfohlen, um die Zeit-Diskrepanz zwischen Client und Server zu reduzieren.

fattr3

struct fattr3 {
   ftype3     type;
   mode3      mode;
   uint32     nlink;
   uid3       uid;
   gid3       gid;
   size3      size;
   size3      used;
   specdata3  rdev;
   uint64     fsid;
   fileid3    fileid;
   nfstime3   atime;
   nfstime3   mtime;
   nfstime3   ctime;
};

Diese Struktur definiert die Attribute eines Dateisystemobjekts. Sie wird von den meisten Operationen auf einem Objekt zurückgegeben; im Fall von Operationen, die zwei Objekte betreffen (zum Beispiel ein MKDIR, das die Zielverzeichnisattribute modifiziert und neue Attribute für das neu erstellte Verzeichnis definiert), können die Attribute für beide zurückgegeben werden. In einigen Fällen werden die Attribute in der unten definierten Struktur wcc_data zurückgegeben; in anderen Fällen werden die Attribute allein zurückgegeben. Die Hauptänderungen gegenüber dem NFS Version 2 Protokoll sind, dass viele der Felder erweitert wurden und die Major/Minor-Geräteinformationen jetzt in einer separaten Struktur dargestellt werden, anstatt in ein Wort gepackt zu werden.

Die fattr3-Struktur enthält die grundlegenden Attribute einer Datei. Alle Server sollten diese Menge von Attributen unterstützen, auch wenn sie einige der Felder simulieren müssen. Type ist der Typ der Datei. Mode sind die Schutzmodusbits. Nlink ist die Anzahl der harten Links zur Datei - das heißt, die Anzahl verschiedener Namen für dieselbe Datei. Uid ist die Benutzer-ID des Eigentümers der Datei. Gid ist die Gruppen-ID der Gruppe der Datei. Size ist die Größe der Datei in Bytes. Used ist die Anzahl der Bytes Festplattenspeicher, die die Datei tatsächlich verwendet (was kleiner als die Größe sein kann, weil die Datei Löcher haben kann, oder größer aufgrund von Fragmentierung). Rdev beschreibt die Gerätedatei, wenn der Dateityp NF3CHR oder NF3BLK ist - siehe specdata3 auf Seite 20. Fsid ist der Dateisystemidentifikator für das Dateisystem. Fileid ist eine Nummer, die die Datei innerhalb ihres Dateisystems eindeutig identifiziert (auf UNIX wäre dies die Inumber). Atime ist die Zeit, zu der die Dateidaten zuletzt zugegriffen wurden. Mtime ist die Zeit, zu der die Dateidaten zuletzt modifiziert wurden. Ctime ist die Zeit, zu der die Attribute der Datei zuletzt geändert wurden. Das Schreiben in die Datei ändert zusätzlich zur mtime auch die ctime.

Die Modusbits sind wie folgt definiert:

0x00800 Setze Benutzer-ID bei Ausführung.
0x00400 Setze Gruppen-ID bei Ausführung.
0x00200 Speichere getauschten Text (nicht in POSIX definiert).
0x00100 Leseberechtigung für Eigentümer.
0x00080 Schreibberechtigung für Eigentümer.
0x00040 Ausführungsberechtigung für Eigentümer auf einer Datei. Oder Such-(Lookup-)Berechtigung für Eigentümer im Verzeichnis.
0x00020 Leseberechtigung für Gruppe.
0x00010 Schreibberechtigung für Gruppe.
0x00008 Ausführungsberechtigung für Gruppe auf einer Datei. Oder Such-(Lookup-)Berechtigung für Gruppe im Verzeichnis.
0x00004 Leseberechtigung für andere.
0x00002 Schreibberechtigung für andere.
0x00001 Ausführungsberechtigung für andere auf einer Datei. Oder Such-(Lookup-)Berechtigung für andere im Verzeichnis.

post_op_attr

union post_op_attr switch (bool attributes_follow) {
case TRUE:
   fattr3   attributes;
case FALSE:
   void;
};

Diese Struktur wird verwendet, um Attribute in Operationen zurückzugeben, die nicht direkt an der Manipulation von Attributen beteiligt sind. Eines der Prinzipien dieser Revision des NFS-Protokolls ist es, den tatsächlichen Wert aus der angegebenen Operation zurückzugeben und nicht einen Fehler aus einer nebensächlichen Operation. Die post_op_attr-Struktur wurde entwickelt, um dem Server zu ermöglichen, sich von Fehlern zu erholen, die beim Abrufen von Attributen auftreten.

Dies scheint die Rückgabe von Attributen optional zu machen. Server-Implementierer werden jedoch nachdrücklich ermutigt, sich nach Kräften zu bemühen, Attribute wann immer möglich zurückzugeben, auch wenn ein Fehler zurückgegeben wird.

wcc_attr

struct wcc_attr {
   size3       size;
   nfstime3    mtime;
   nfstime3    ctime;
};

Dies ist die Teilmenge der Präoperationsattribute, die benötigt wird, um die Semantik der schwachen Cache-Konsistenz besser zu unterstützen. Size ist die Dateigröße in Bytes des Objekts vor der Operation. Mtime ist die Zeit der letzten Modifikation des Objekts vor der Operation. Ctime ist die Zeit der letzten Änderung der Attribute des Objekts vor der Operation. Siehe Diskussion in wcc_attr auf Seite 24.

Die Verwendung von mtime durch Clients zur Erkennung von Änderungen an Dateisystemobjekten, die sich auf einem Server befinden, ist abhängig von der Granularität der Zeitbasis auf dem Server.

pre_op_attr

union pre_op_attr switch (bool attributes_follow) {
case TRUE:
     wcc_attr  attributes;
case FALSE:
     void;
};

wcc_data

struct wcc_data {
   pre_op_attr    before;
   post_op_attr   after;
};

Wenn ein Client eine Operation durchführt, die den Zustand einer Datei oder eines Verzeichnisses auf dem Server modifiziert, kann er aus den Postoperationsattributen nicht sofort bestimmen, ob die gerade durchgeführte Operation die einzige Operation am Objekt seit dem letzten Empfang der Attribute für das Objekt durch den Client war. Dies ist wichtig, denn wenn eine zwischenzeitliche Operation das Objekt geändert hat, muss der Client alle zwischengespeicherten Daten für das Objekt ungültig machen (außer den Daten, die er gerade geschrieben hat).

Um damit umzugehen, wird das Konzept der schwachen Cache-Konsistenzdaten oder wcc_data eingeführt. Eine wcc_data-Struktur besteht aus bestimmten Schlüsselfeldern aus den Objektattributen vor der Operation zusammen mit den Objektattributen nach der Operation. Diese Informationen ermöglichen es dem Client, seinen Cache genauer zu verwalten als in NFS Version 2 Protokollimplementierungen. Der Begriff schwache Cache-Konsistenz betont die Tatsache, dass dieser Mechanismus nicht die strenge Server-Client-Konsistenz bietet, die ein Cache-Konsistenzprotokoll bieten würde.

Um das Modell der schwachen Cache-Konsistenz zu unterstützen, muss der Server in der Lage sein, die Präoperationsattribute des Objekts zu erhalten, die beabsichtigte Modifikationsoperation durchzuführen und dann atomar die Postoperationsattribute zu erhalten. Wenn es ein Fenster gibt, in dem das Objekt zwischen der Operation und einer der Get-Attributes-Operationen modifiziert werden kann, dann kann der Client nicht bestimmen, ob er die einzige Entität war, die das Objekt modifiziert hat. Einige Informationen sind verloren gegangen, wodurch die Garantien der schwachen Cache-Konsistenz geschwächt werden.

post_op_fh3

union post_op_fh3 switch (bool handle_follows) {
case TRUE:
     nfs_fh3  handle;
case FALSE:
     void;
};

Eines der Prinzipien dieser Revision des NFS-Protokolls ist es, den tatsächlichen Wert aus der angegebenen Operation zurückzugeben und nicht einen Fehler aus einer nebensächlichen Operation. Die post_op_fh3-Struktur wurde entwickelt, um dem Server zu ermöglichen, sich von Fehlern zu erholen, die beim Konstruieren eines Datei-Handles auftreten.

Dies ist die Struktur, die verwendet wird, um ein Datei-Handle aus den Anfragen CREATE, MKDIR, SYMLINK, MKNOD und READDIRPLUS zurückzugeben. In jedem Fall kann der Client das Datei-Handle erhalten, indem er nach einer erfolgreichen Rückkehr von einer der aufgelisteten Operationen eine LOOKUP-Anfrage ausgibt. Die Rückgabe des Datei-Handles ist eine Optimierung, sodass der Client nicht gezwungen ist, sofort eine LOOKUP-Anfrage auszugeben, um das Datei-Handle zu erhalten.

sattr3

enum time_how {
   DONT_CHANGE        = 0,
   SET_TO_SERVER_TIME = 1,
   SET_TO_CLIENT_TIME = 2
};

union set_mode3 switch (bool set_it) {
case TRUE:
   mode3    mode;
default:
   void;
};

union set_uid3 switch (bool set_it) {
case TRUE:
   uid3     uid;
default:
   void;
};

union set_gid3 switch (bool set_it) {
case TRUE:
   gid3     gid;
default:
   void;
};

union set_size3 switch (bool set_it) {
case TRUE:
   size3    size;
default:
   void;
};

union set_atime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
   nfstime3  atime;
default:
   void;
};

union set_mtime switch (time_how set_it) {
case SET_TO_CLIENT_TIME:
   nfstime3  mtime;
default:
   void;
};

struct sattr3 {
   set_mode3   mode;
   set_uid3    uid;
   set_gid3    gid;
   set_size3   size;
   set_atime   atime;
   set_mtime   mtime;
};

Die sattr3-Struktur enthält die Dateiattribute, die vom Client gesetzt werden können. Die Felder sind dieselben wie die ähnlich benannten Felder in der fattr3-Struktur. Im NFS Version 3 Protokoll werden die setzbaren Attribute durch eine Struktur beschrieben, die eine Menge diskriminierter Unions enthält. Jede Union gibt an, ob das entsprechende Attribut aktualisiert werden soll und wenn ja, wie.

Es werden zwei Formen diskriminierter Unions verwendet. Beim Setzen von mode, uid, gid oder size wird die diskriminierte Union über einen Boolean, set_it, geschaltet; wenn dieser TRUE ist, wird dann ein Wert des entsprechenden Typs kodiert.

Beim Setzen von atime oder mtime wird die Union über einen Aufzählungstyp, set_it, geschaltet. Wenn set_it den Wert DONT_CHANGE hat, bleibt das entsprechende Attribut unverändert. Wenn es den Wert SET_TO_SERVER_TIME hat, wird das entsprechende Attribut vom Server auf seine Ortszeit gesetzt; vom Client werden keine Daten bereitgestellt. Schließlich, wenn set_it den Wert SET_TO_CLIENT_TIME hat, wird das Attribut auf die Zeit gesetzt, die der Client in einer nfstime3-Struktur übergeben hat. (Siehe FSINFO auf Seite 86, das die Frage der Zeitgranularität behandelt).

diropargs3

struct diropargs3 {
   nfs_fh3     dir;
   filename3   name;
};

Die diropargs3-Struktur wird in Verzeichnisoperationen verwendet. Das Datei-Handle, dir, identifiziert das Verzeichnis, in dem die Datei, name, manipuliert oder auf sie zugegriffen werden soll. Siehe zusätzliche Kommentare in Dateinamenkomponentenbehandlung auf Seite 101.

Letztes Update am