Ubuntu Manpage: open, openat, creat - eine Datei öffnen und möglicherweise erzeugen

BEZEICHNUNG

       open, openat, creat - eine Datei öffnen und möglicherweise erzeugen

ÜBERSICHT

       #include <sys/types.h>
       #include <sys/stat.h>
       #include <fcntl.h>

       int open(const char *pathname, int flags);
       int open(const char *pathname, int flags, mode_t mode);

       int creat(const char *pathname, mode_t mode);

       int openat(int dirfd, const char *pathname, int flags);
       int openat(int dirfd, const char *pathname, int flags, mode_t mode);

   Mit Glibc erforderliche Makros (siehe feature_test_macros(7)):

       openat():
           Seit Glibc 2.10:
               _POSIX_C_SOURCE >= 200809L
           Vor Glibc 2.10:
               _ATFILE_SOURCE

BESCHREIBUNG

Der Systemaufruf open() öffnet eine durch pathname festgelegte Datei. Falls die angegebene
Datei nicht existiert, kann sie optional (falls O_CREAT in flags festgelegt wurde) durch
open() erstellt werden.

Der Rückgabewert von open() ist ein Dateideskriptor, eine kleine, nicht negative Ganzzahl,
die in nachfolgenden Systemaufrufen (read(2), write(2), lseek(2), fcntl(2) usw.) genutzt
wird, um den Bezug zu der offenen Datei herzustellen. Der bei einem erfolgreichen Aufruf
zurückgelieferte Dateideskriptor wird der niedrigstzahlige, noch nicht für den Prozess
offene Dateideskriptor sein.

Standardmäßig bleibt der neue Dateideskriptor über ein execve(2) offen (d.h. der in
fcntl(2) beschriebene Dateideskriptorschalter FD_CLOEXEC ist anfangs leer). Der weiter
unten beschriebene Schalter O_CLOEXEC kann zum Ändern dieser Vorgabe verwandt werden. Der
Dateiversatz wird auf den Anfang der Datei gesetzt (siehe lseek(2)).

Ein Aufruf von open() erstellt eine neue offene Dateideskription, einen Entrag in der
systemweiten Tabelle von offenen Dateien. Die offene Dateideskription zeichnet den
Dateiversatz und die Dateizustandsschalter (siehe unten) auf. Ein Dateideskriptor ist eine
Referenz auf eine offene Dateideskription. Diese Referenz ist nicht betroffen, falls
pathname im Folgenden entfernt oder so verändert wird, dass er auf eine andere Datei
zeigt. Für weitere Details über offene Dateideskriptionen, siehe ANMERKUNGEN.

Das Argument flags muss einen der folgenden Zugriffsmodi enthalten: O_RDONLY, O_WRONLY
oder O_RDWR. Diese erbitten, die Datei nur lesbar, nur schreibbar bzw. les-/schreibbar zu
öffnen.

Zusätzlich können Null oder mehr Dateierstellungsschalter in flags mit einem bitweisen
Oder zusammengebracht werden. Die Dateierstellungsschalter sind O_CLOEXEC, O_CREAT,
O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, O_TMPFILE und O_TRUNC. Die restlichen unten
aufgeführten Schalter sind die Dateistatusschalter. Der Unterschied zwischen diesen zwei
Gruppen von Schaltern besteht darin, dass die Dateierstellungsschalter die Semantik der
Open-Aktion selbst betreffen, während die Dateistatusschalter die Semantik der
nachfolgenden E/A-Aktionen betreffen. Die Dateistatussschalter können abgefragt und (in
einigen Fällen) verändert werden; siehe fcntl(2) für Details.

Die komplette Liste der Dateierstellungs- und Dateistatusschalter ist wie folgt:

O_APPEND
Die Datei wird im Anhängemodus geöffnet. Vor jedem write(2) wird der Dateiversatz
an das Ende der Datei positioniert, wie mit lseek(2). Die Veränderung des
Dateiversatzes und die Schreibaktion werden als einzelner, atomarer Schritt
durchgeführt.

O_APPEND kann auf NFS-Dateisystemen zu beschädigten Dateien führen, falls mehr als
ein Prozess auf einmal Daten an die Datei anhängt. Dies kommt daher, da NFS das
Anhängen an Dateien nicht unterstützt und der Client-Kernel dies daher simulieren
muss, was nicht ohne einen Wettlauf um Ressourcen passieren kann.

O_ASYNC
Aktiviert signalgetriebene E/A: erzeugt ein Signal (standardmäßig SIGIO, dies kann
aber mit fcntl(2) geändert werden), wenn Ein- oder Ausgabe auf diesem
Dateideskriptor möglich wird. Diese Funktionalität ist nur für Terminals,
Pseudoterminals, Sockets und (seit Linux 2.6) Pipes und FIFOs verfügbar. Siehe
fcntl(2) für weitere Details. Siehe auch FEHLER unten.

O_CLOEXEC (seit Linux 2.6.23)
Aktiviert den Schalter »close-on-exec« für den neuen Dateideskriptor. Durch
Festlegung dieses Schalters wird einem Programm ermöglicht, zusätzliche
fcntl(2)-F_SETFD-Aktionen, um den Schalter FD_CLOEXEC zu setzen, zu vermeiden.

Beachten Sie, dass die Verwendung dieses Schalters in einigen
Multithread-Programmen notwendig ist, da die Verwendung einer separaten
fcntl(2)-F_SETFD-Aktion, um den Schalter FD_CLOEXEC zu setzen, nicht ausreicht, um
eine Race-Condition zu vermeiden, bei der ein Thread einen Dateideskriptor öffnet
und versucht, dessen close-on-exec-Schalter mittels fcntl(2) zur gleichen Zeit zu
setzen, zu der ein anderer Thread einen fork(2) kombiniert mit eine execve(2)
durchführt. Abhängig von der Reihenfolge der Ausführung kann der Ressourcenwettlauf
dazu führen, dass der von open(2) zurückgelieferte Dateideskriptor ungeplant von
dem Programm durchgesickert ist, das von dem Kindprozess mittels fork(2) erzeugt
wurde. (Diese Art von Ressourcenwettlauf ist prinzipiell für jeden Systemaufruf
möglich, der einen Dateideskriptor erstellt, dessen Schalter close-on-exec gesetzt
sein solte, und verschiedene andere Linux-Systemaufrufe stellen ein Äquivalent zu
dem Schalter O_CLOEXEC bereit, um mit diesem Problem umzugehen.

O_CREAT
Falls pathname nicht existiert, wird eine normale Datei erstellt.

Der Eigentümer (Benutzerkennung) der neuen Datei wird auf die effektive
Benutzerkennung des Prozesses gesetzt.

Die Gruppen-Eigentümerschaft (Gruppenkennung) der neuen Datei wird entweder auf die
effektive Gruppenkennung des Prozesses (System-V-Semantik) oder auf die
Gruppenkennung des Elternverzeichnisses (BSD-Semantik) gesetzt. Unter Linux hängt
das Verhalten davon ab, ob das Modusbit set-group-ID auf dem Elternverzeichnis
gesetzt ist. Falls das Bit gesetzt ist, gilt die BSD-Semantik, andernfalls gilt die
System-V-Semantik. Bei einigen Dateisystemen hängt das Verhalten von den in
mount(8) beschriebenen Einhängeoptionen bsdgroups und sysvgroups ab.

Das Argument mode legt die Dateimodusbits, die beim Erstellen einer neuen Dateien
angewandt werden sollen, fest. Das Argument muss bereitgestellt werden, wenn
O_CREAT oder O_TMPFILE in flags festgelegt wird. Falls weder O_CREAT noch O_TMPFILE
festgelegt ist, wird mode ignoriert. Der effektive Modus wird durch die umask des
Prozesses wie üblich verändert: in der Abwesenheit einer Standard-ACL ist der Modus
der erstellten Datei (mode & ~umask). Beachten Sie, dass dieser Modus nur bei
zukünftigen Zugriffen auf die neu erstellte Datei gilt; der Aufruf open(), der eine
nur-lesbare Datei erstellte, kann sehr wohl einen lese- und schreibbaren
Dateideskriptor zurückliefern.

Für mode werden die folgenden symbolischen Konstanten bereitgestellt:

S_IRWXU 00700 Benutzer (Dateieigentümer) hat Lese-, Schreibe- und Ausführrechte

S_IRUSR 00400 Benutzer hat Leserechte

S_IWUSR 00200 Benutzer hat Schreibrechte

S_IXUSR 00100 Benutzer hat Ausführrechte

S_IRWXG 00070 Gruppe hat Lese-, Schreib- und Ausführrechte

S_IRGRP 00040 Gruppe hat Leserechte

S_IWGRP 00020 Gruppe hat Schreibrechte

S_IXGRP 00010 Gruppe hat Ausführrechte

S_IRWXO 00070 andere haben Lese-, Schreib- und Ausführrechte

S_IROTH 00004 andere haben Leserechte

S_IWOTH 00002 andere haben Schreibrechte

S_IXOTH 00001 andere haben Ausführrechte

Laut POSIX ist der Effekt, wenn andere Bits in mode gesetzt werden, nicht
spezifiziert. Unter Linux werden auch die folgenden Bits in mode berücksichtigt:

S_ISUID 0004000 set-user-ID-Bit

S_ISGID 0002000 set-group-ID-Bit (siehe inode(7))

S_ISVTX 0001000 Sticky-Bit (siehe inode(7))

O_DIRECT (seit Linux 2.4.10)
versucht die Zwischenspeichereffekte auf die E/A in und aus dieser Datei zu
minimieren. Im Allgemeinen reduziert das die Leistung, aber in besonderen
Situationen ist das nützlich, beispielsweise wenn Anwendungen ihre eigene
Zwischenspeicherung vornehmen. Datei-E/A erfolgt direkt aus den Puffern des
Benutzerraums. Der Schalter O_DIRECT versucht, Daten synchron zu übertragen, gibt
aber nicht die Garantien des Schalters O_SYNC, dass Daten und notwendige Metadaten
übetragen wurden. Um synchrone E/A zu garantieren, muss O_SYNC zusätzlich zu
O_DIRECT verwandt werden. Siehe ANMERKUNGEN für weitere Betrachtungen.

Eine semantisch ähnliche (aber misbilligte) Schnittstelle für Blockgeräte wird in
raw(8) beschrieben.

O_DIRECTORY
Falls pathname kein Verzeichnis ist, schlägt damit open fehl. Dieser Schalter wurde
in Kernel-Version 2.1.126 hinzugefügt, um Diensteverweigerungsangriffe zu
vermeiden, falls opendir(3) mit einem FIFO oder Bandgerät aufgerufen wird.

O_DSYNC
Schreibaktionen auf der Datei werden entsprechend den Anforderungen der
synchronisierten E/A-Daten-Integritätsvervollständigung vervollständigt.

Zum Zeitpunkt der Rückkehr von write(2) (und ähnlichen) sind die Ausgabedaten zur
darunterliegenden Hardware übertragen worden, zusammen mit allen Dateimetadaten,
die zum Abfragen der Daten benötigt würden (d.h. als ob jedem write(2) ein Aufruf
von fdatasync(2) gefolgt wäre). Siehe Hinweise unten.

O_EXCL stellt sicher, dass dieser Aufruf die Datei erstellt. Falls dieser Schalter
zusammen mit O_CREAT festgelegt wird und pathname bereits existiert, dann schlägt
open() mit dem Fehler EEXIST fehl.

Wenn diese zwei Schalter festgelegt werden, wird symbolischen Links nicht gefolgt.
Falls pathname ein symbolischer Link ist, dann schlägt open() fehl, unabhängig
davon, wohin der symbolische Link verweist.

Im Allgemeinen ist das Verhalten von O_EXCL undefiniert, falls es ohne O_CREAT
verwandt wird. Es gibt eine Ausnahme: Unter Linux 2.6 und neuer kann O_EXCL ohne
O_CREAT verwandt werden, falls sich pathname auf ein Blockgerät bezieht. Falls das
Blockgerät vom System verwandt (d.h. eingehängt) ist, schlägt open() mit dem Fehler
EBUSY fehl.

Unter NFS wird O_EXCL nur beim Einsatz von NFSv3 oder neuer unter Kernel 2.6 oder
neuer unterstützt. In NFS-Umgebungen, in denen keine Unterstützung für O_EXCL
bereit steht, werden Programme, die sich für Sperrungen darauf verlassen, eine
Race-Condition enthalten. Portable Programme, die atomares Dateisperren mittels
einer Sperrdatei durchführen wollen, und eine Abhängigkeit auf die Unterstützung
von O_EXCL duch NFS vermeiden müssen, können eine eindeutige Datei auf dem gleichen
Dateisystem erstellen (d.h. den Rechnernamen und die PID einbauen) und link(2)
verwenden, um einen Link auf die Sperrdatei zu erstellen. Falls link(2) den Wert 0
zurückliefert, war die Sperrung erfolgreich. Andernfalls verwenden Sie stat(2) auf
einer eindeutigen Datei, um zu prüfen, ob die Link-Anzahl sich auf 2 erhöht hat.
Falls das der Fall ist, war die Sperre auch erfolgreich.

O_LARGEFILE
(LFS) Erlaubt Dateien, deren Größe nicht in einem off_t (aber in einem off64_t)
dargestellt werden kann, geöffnet zu werden. Das Makro _LARGEFILE64_SOURCE muss
(vor dem Einbinden aller Header-Dateien) definiert sein, um diese Definition zu
erhalten. Das Setzen des Feature-Test-Makros _FILE_OFFSET_BITS auf 64 (statt der
Verwendung von O_LARGEFILE) ist die bevorzugte Methode zum Zugriff auf große
Dateien auf 32-Bit-Systemen (siehe feature_test_macros(7)).

O_NOATIME (seit Linux 2.6.8)
Aktualisiert die letzte Zugriffszeit der Datei (st_atime in dem Inode) nicht, wenn
ein read(2) auf der Datei erfolgt.

Dieser Schalter kann nur verwandt werden, falls eine der folgenden Bedingungen
zutrifft:

* Die effektive UID des Prozesses passt auf die Eigentümer-UID des Datei.

* Der aufrufende Prozess verfügt über die Capability CAP_FOWNER in seinem
Benutzernamensraum und es gibt eine Abbildung der Benutzer-UID der Datei in den
Namensraum.

Dieser Schalter ist für Indizierungs- und Backup-Programme gedacht, bei denen
dessen Verwendung die Plattenaktivität signifikant reduzieren kann. Dieser Schalter
funktioniert möglicherweise nicht auf allen Dateisystemen. Beispielsweise verwaltet
bei NFS der Server die Zugriffszeit.

O_NOCTTY
Falls sich pathname auf ein Terminalgerät – siehe tty(4) – bezieht, wird es nicht
das steuernde Terminal des Prozesses werden, selbst falls der Prozess noch keines
hat.

O_NOFOLLOW
Falls pathname ein symbolischer Link ist, schlägt das Öffnen mit dem Fehler ELOOP
fehl. Symbolische Links in früheren Komponenten des Pfadnamens werden weiterhin
aufgelöst. (Beachten Sie, dass der in diesem Fall möglich Fehler ELOOP
ununterscheidbar vom dem Fall ist, in dem ein Öffnen fehlschlägt, da es zu viele
symbolische Links beim Auflösen von Komponenten im Präfixanteil des Pfadnamens
gibt.)

Dieser Schalter ist eine FreeBSD-Erweiterung, die in Version 2.1.126 in Linux
hinzugefügt und schließlich in POSIX.1-2008 standardisiert wurde.

Siehe auch O_PATH weiter unten.

O_NONBLOCK oder O_NDELAY
Falls möglich, wird die Datei im nichtblockierenden Modus geöffnet. Weder das
open() noch folgende E/A-Aktionen auf dem zurückgegebenen Dateideskriptor werden
dazu führen, dass der aufrufende Prozess warten muss.

Beachten Sie, dass das Setzen dieses Schalters keine Wirkung auf die Aktion von
poll(2), select(2), epoll(7) und ähnlichen Funktionen hat, da deren Schnittstellen
den Aufrufenden lediglich darüber informieren, ob ein Dateideskriptor »bereit« ist,
was bedeutet, dass eine auf dem Datei-Deskriptor durchgeführte E/A-Aktion mit dem
O_NONBLOCK-Schalter clear nicht blockieren würde.

Beachten Sie, dass dieser Schalter für reguläre Dateien und Blockgeräte keinen
Effekt hat. Dies bedeutet, E/A-Aktionen werden (kurz) blockieren, wenn eine
Geräteaktivität benötigt wird, unabhängig davon, ob O_NONBLOCK gesetzt ist. Da die
Semantik von O_NONBLOCK irgendwann einmal implementiert werden könnte, sollten
Anwendungen nicht vom blockierenden Verhalten bei regulären Dateien und
Blockgeräten bei der Angabe dieses Schalters abhängen.

Für die Handhabung von FIFOs (benannten Pipes), siehe auch fifo(7). Für eine
Diskussion des Effekts von O_NONBLOCK im Zusammenhang mit verpflichtenden Sperren
und mit Datei-Ausleihen, siehe fcntl(2).

O_PATH (seit Linux 2.6.39)
Erhält einen Dateideskriptor, der für zwei Zwecke eingesetzt werden kann: um den
Ort im Dateisystembaum anzuzeigen und um Aktionen durchzuführen, die rein auf der
Dateideskriptorebene agieren. Die Datei selbst wird nicht geöffnet und andere
Dateiaktionen (z.B. read(2), write(2), fchmod(2), fchown(2), fgetxattr(2),
ioctl(2), mmap(2)) schlagen mit dem Fehler EBADF fehl.

Die folgenden Aktionen können mit dem entstandenen Dateideskriptor durchgeführt
werden:

* close(2).

* fchdir(2), falls der Dateideskriptor auf ein Verzeichnis verweist (seit Linux
3.5).

* fstat(2) (seit Linux 3.6).

* fstatfs(2) (seit Linux 3.12).

* Duplizieren des Dateideskriptors (dup(2), fcntl(2) F_DUPFD, usw.).

* Ermitteln und Setzen von Dateideskriptorenschaltern (fcntl(2) F_GETFD und
F_SETFD).

* Ermitteln von offenen Dateistatusschaltern mittels der Aktion F_GETFL von
fcntl(2): Die zurückgelieferten Schalter werden das Bit O_PATH enthalten.

* Übergabe des Dateideskriptors als Argument dirfd von openat() und den anderen
»*at()«-Systemaufrufen. Dazu gehört linkat(2) mit AT_EMPTY_PATH (oder mittels
AT_SYMLINK_FOLLOW von Procfs), selbst falls die Datei kein Verzeichnis ist.

* Übergabe des Dateideskriptors an einen anderen Prozess mittels
UNIX-Domain-Sockets (siehe SCM_RIGHTS in unix(7)).

Wenn O_PATH in flags angegeben ist, werden die von O_CLOEXEC, O_DIRECTORY und
O_NOFOLLOW verschiedenen Schalter-Bits ignoriert.

Öffnen einer Datei oder eines Verzeichnisses mit dem Schalter O_PATH benötigt keine
Rechte an dem Objekt selber (allerdings benötigt es Ausführrechte auf den
Verzeichnissen im Pfadpräfix). Abhängig von nachfolgenden Aktionen kann eine
Überprüfung auf geeignete Dateiberechtigungen durchgeführt werden (z.B. benötigt
fchdir(2) Ausführrechte auf das durch sein Dateideskriptorargument referenzierte
Verzeichnis). Im Gegensatz dazu benötigt das Erlangen einer Referenz auf ein
Dateisystemobjekt durch Öffen mit dem Schalter O_RDONLY, dass der Aufrufende
Leseberechtigungen am Objekt hat, selbst wenn nachfolgende Aktionen (z.B.
fchdir(2), fstat(2)) keine Leseberechtigungen am Objekt benötigen.

Falls pathname ein symbolischer Link ist und auch der Schalter O_NOFOLLOW angegeben
ist, dann liefert der Aufruf einen Dateideskriptor zurück, der sich auf den
symbolischen Link bezieht. Dieser Dateideskriptor kann als Argument dirfd in
Aufrufen von fchownat(2), fstatat(2), linkat(2) und readlinkat(2) mit einem leeren
Dateinamen verwandt werden, um Aufrufe auf den symbolischen Link anzuwenden.

Falls sich pathname auf einen Selbsteinhängepunkt bezieht, der noch nicht ausgelöst
wurde, so dass dort noch kein Dateisystem eingehängt ist, dann wird der Aufruf
einen Dateideskriptor zurückliefern, der sich auf das Selbsteinhängeverzeichnis
bezieht, ohne das Einhängen auszulösen. fstatfs(2) kann dann dazu verwandt werden,
zu bestimmen, ob es sich tatsächlich um ein unausgelösten Selbsteinhängepunkt
handelt (.f_type == AUTOFS_SUPER_MAGIC).

Eine Einsatz von O_PATH für reguläre Dateien ist die Bereitstellung des Äquivalents
der Funktionalität O_EXEC von POSIX.1. Dies erlaubt es, eine Datei zu öffen, für
die Ausführ- aber keine Leserechte vorliegen, und dann diese Datei mittels
Schritten der folgenden Art auszuführen:

char buf[PATH_MAX];
fd = open("ein_Programm", O_PATH);
snprintf(buf, PATH_MAX, "/proc/self/fd/%d", fd);
execl(buf, "ein_Programm", (char *) NULL);

Ein O_PATH-Dateideskriptor kann auch an das Argument von fexecve(3) weitergegeben
werden.

O_SYNC Schreibaktionen auf dieser Datei werden entsprechend den Anforderungen der
synchronisierten E/A-Datei-Integritätsvervollständigung vervollständigt (in
Kontrast zu der durch O_DSYNC bereitgestellten synchronisierten
E/A-Datei-Integritätsvervollständigung).

Zum Zeitpunkt, zu dem write(2) (und ähnliche) zurückkehrt, wurden die Ausgabedaten
und zugehörigen Dateimetadaten bereits an die darunterliegende Hardware übergeben
(d.h. als ob jeder write(2) von einem Aufruf von fsync(2) gefolgt worden wäre.)
Siehe ANMERKUNGEN unten.

O_TMPFILE (seit Linux 3.11)
Erstellt eine unbenannte temporäre normale Datei. Das Argument pathname legt ein
Verzeichnis fest; ein unbenannter Inode wird in dem Dateisystem dieses
Verzeichnisses erstellt. Alles, was in die entstandene Datei geschrieben wird, geht
verloren, wenn der letzte Dateideskriptor geschlossen wird, sofern der Datei nicht
ein Name gegeben wurde.

O_TMPFILE muss als eines aus O_RDWR oder O_WRONLY und optional O_EXCL festgelegt
werden. Falls O_EXCL nicht festgelegt wird, dann kann linkat(2) dazu verwandt
werden, die temporäre Datei in das Dateisystem zu linken, womit diese permanent
wird, unter Verwendung von Code wie dem folgenden:

char path[PATH_MAX];
fd = open("/Pfad/zu/Verz", O_TMPFILE | O_RDWR,
S_IRUSR | S_IWUSR);

/* Datei-E/A auf »fd«… */

snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/Pfad/zur/Datei",
AT_SYMLINK_FOLLOW);

In diesem Fall bestimmt das Argument mode von open() den Dateirechtemodus, wie bei
O_CREAT.

Wird O_EXCL in Zusammenhang mit O_TMPFILE festgelegt, dann wird verhindert, dass
die Datei in das Dateisystem in der oben beschriebenen Weise gelinkt wird.
(Beachten Sie, dass die Bedeutung von O_EXCL in diesem Fall anders als sonst ist.)

Es gibt zwei Haupteinsatzgebiete für O_TMPFILE:

* Verbesserte Funktionalität von tmpfile(3): Ressourcen-Wettstreit-freie
Erstellung temporärer Dateien die (1) automatisch gelöscht werden, wenn sie
geschlossen werden; die (2) niemals mittels irgend eines Dateinamens erreicht
werden können; die (3) nicht Subjekt eines Symlink-Angriffs sind und die (4)
nicht vom Aufrufenden verlangen, sich eindeutige Namen auszudenken.

* Erstellen einer Datei, die ursprünglich unsichtbar ist, die dann mit den Daten
gefüllt und angepasst wird, um die korrekten Dateisystemattribute zu erhalten
((fchown(2), fchmod(2), fsetxattr(2) usw.), bevor sie atomar in das Dateisystem
in einer vollständigen Form gelinkt wird (mittels linkat(2) wie oben
beschrieben).

O_TMPFILE benötigt die Unterstützung des zugrundeliegenden Dateisystems. Nur eine
Teilmenge der Linux-Dateisysteme unterstützt dies. In der anfänglichen
Implementierung wurde die Unterstützung für die Dateisysteme Ext2, Ext3, Ext4, UDF,
Minix und Shmem bereitgestellt. Die Unterstützung für weitere Dateisysteme wurde
später wie folgt hinzugefügt: XFS (Linux 3.15), Btrfs (Linux 3.16), F2FS (Linux
3.16) und Ubifs (Linux 4.9).

O_TRUNC
Falls die Datei bereits existiert, eine reguläre Datei ist und der Zugriffsmodus
Schreiben erlaubt (d.h. O_RDWR oder O_WRONLY ist), dann wird sie auf die Länge 0
abgeschnitten. Falls die Datei ein FIFO oder Terminalgerät ist, dann wird der
Schalter O_TRUNC ignoriert. Andernfalls ist die Auswirkung von O_TRUNC nicht
festgelegt.

creat()
Ein Aufruf von creat() is äquivalent zum Aufruf von open() mit flags identisch zu
O_CREAT|O_WRONLY|O_TRUNC.

openat()
Der Systemaufruf openat() arbeitet genau wie open(), außer den hier beschriebenen
Unterschieden.

Falls der in pathname angegebene Pfadname relativ ist, dann wird er relativ zu dem
Verzeichnis interpretiert, auf das der Dateideskriptor dirfd verweist (statt relativ zu
dem aktuellen Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei open() für einen
relativen Pfadnamen erfolgt).

Falls pathname relativ ist und dirfd den speziellen Wert AT_FDCWD enthält, dann wird
pathname relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert
(wie open()).

Falls Pfadname absolut ist wird dirfd ignoriert.

RÜCKGABEWERT

       open(), openat() und creat() liefern den neuen Dateideskriptor zurück oder -1,  falls  ein
       Fehler auftrat (in diesem Fall wird errno entsprechend gesetzt).

FEHLER

open(), openat() und creat() können mit den folgenden Fehlern fehlschlagen:

EACCES Der angeforderte Zugriff auf die Datei ist nicht erlaubt oder die Suchberechtigung
ist für eines der Verzeichnisse im Pfadanteil von pathname verweigert oder die
Datei existierte noch nicht oder Schreibzugriff auf das Elternverzeichnis ist nicht
erlaubt. (Siehe auch path_resolution(7).)

EDQUOT Wo O_CREAT angegeben ist existiert die Datei nicht und die Quota des Benutzers an
Plattenblöcken oder Inodes auf dem Dateisystem ist erschöpft.

EEXIST pathname existiert bereits und O_CREAT und O_EXCL wurden verwandt.

EFAULT pathname zeigt aus dem für Sie zugänglichen Adressraum heraus.

EFBIG siehe EOVERFLOW

EINTR Während der Aufruf wartet, bis ein langsames Gerät vollständig geöffnet ist (z.B.
ein FIFO, siehe fifo(7)), wurde er von einem Signal-Handler unterbrochen, siehe
signal(7).

EINVAL Das Dateisystem unterstützt den Schalter O_DIRECT nicht. Lesen Sie ANMERKUNGEN für
weitere Informationen.

EINVAL Unzulässiger Wert in flags.

EINVAL O_TMPFILE wurde in flags angegeben, aber weder O_WRONLY noch O_RDWR wurden
angegeben.

EINVAL O_CREAT wurde in flags angegeben und die abschließende Komponente (»basename«) des
pathname der neuen Datei ist ungültig (d.h. sie enthält im unterliegenden
Dateisystem nicht erlaubte Zeichen).

EISDIR pathname bezieht sich auf ein Verzeichnis und der Zugriff beinhaltete Schreiben
(d.h. O_WRONLY oder O_RDWR ist gesetzt).

EISDIR pathname bezieht sich auf ein existierendes Verzeichnis, O_TMPFILE und entweder
O_WRONLY oder O_RDWR wurde in flags angegeben, aber diese Kernelversion stellt die
Funktionalität O_TMPFILE nicht zur Verfügung.

ELOOP Bei der Auflösung von pathname wurden zu viele symbolische Links gefunden.

ELOOP pathname war ein symbolischer Link und flags legte O_NOFOLLOW aber nicht O_PATH
fest.

EMFILE Die pro-Prozess-Begrenzung der Anzahl offener Dateideskriptoren wurde erreicht
(siehe die Beschreibung von RLIMIT_NOFILE in getrlimit(2)).

ENAMETOOLONG
pathname war zu lang.

ENFILE Die systemweite Beschränkung für die Gesamtzahl offener Dateien wurde erreicht.

ENODEV pathname bezieht sich auf eine Geräte-Spezialdatei und kein entsprechendes Gerät
existiert. (Dies ist ein Fehler im Linux-Kernel; in dieser Situation muss ENXIO
zurückgeliefert werden.)

ENOENT O_CREAT ist nicht gesetzt und die angegebene Datei existiert nicht.

ENOENT Eine Verzeichniskomponente von pathname existiert nicht oder ist ein toter
symbolischer Link.

ENOENT pathname bezieht sich auf ein nicht existierendes Verzeichnis, O_TMPFILE und
entweder O_WRONLY oder O_RDWR wurde in flags angegeben, aber diese Kernelversion
stellt die Funktionalität O_TMPFILE nicht zur Verfügung.

ENOMEM Die benannte Datei ist ein FIFO, aber der Speicher für den FIFO-Puffer kann nicht
bereitgestellt werden, da die benutzerbezogene harte Grenze bezüglich
Speicherzuweisung für Pipes erreicht wurde und der Aufrufende keine Privilegien
hat; siehe pipe(7).

ENOMEM Es war nicht genügend Kernelspeicher verfügbar.

ENOSPC pathname sollte erstellt werden, aber das Gerät, das pathname enthält, hat für die
neue Datei keinen Platz.

ENOTDIR
Eine als Verzeichnis verwandte Komponente in pathname ist tatsächlich kein
Verzeichnis oder O_DIRECTORY wurde angegeben, aber pathname war kein Verzeichnis.

ENXIO O_NONBLOCK | O_WRONLY ist gesetzt, die benannte Datei ist ein FIFO und kein Prozess
hat den FIFO zum Lesen offen.

ENXIO Die Datei ist eine Geräte-Spezialdatei und kein entsprechendes Gerät existiert.

ENXIO Die Datei ist ein UNIX Domain Socket.

EOPNOTSUPP
Das Dateisystem, das pathname enthält, unterstützt O_TMPFILE nicht.

EOVERFLOW
pathname bezieht sich auf eine normale Datei, die zu groß zum Öffnen ist. Das
normale Szenario ist, dass eine auf einer 32-Bit-Plattform ohne
-D_FILE_OFFSET_BITS=64 übersetzte Anwendung versuchte, eine Datei zu öffnen, deren
Größe (1<<31)-1 byte überschritt; siehe auch O_LARGEFILE weiter oben. Dies ist der
durch POSIX.1 festgelegte Fehler; in Kerneln vor 2.6.24 gab Linux in diesem Fall
den Fehler EFBIG zurück.

EPERM Der Schalter O_NOATIME war festgelegt, aber die effektive Benutzerkennung des
Aufrufenden passte nicht auf den Eigentümer der Datei und der Aufrufende war nicht
privilegiert.

EPERM Die Aktion wurde durch eine Dateiversiegelung verhindert; siehe fcntl(2).

EROFS pathname bezieht sich auf eine Datei auf einem schreibgeschützten Dateisystem, und
Schreibzugriff wurde angefordert.

ETXTBSY
pathname bezieht sich auf ein ausführbares Abbild, das derzeit ausgeführt wird und
Schreibzugriff wurde erbeten.

ETXTBSY
pathname bezieht sich auf eine Datei, die derzeit als Auslagerungsdatei verwandt
wird und O_TRUNC wurde festgelegt.

ETXTBSY
pathname bezieht sich auf ein Datei, die derzeit vom Kernel gelesen wird (z.B. für
das Laden von Modulen/Firmware) und Schreibzugriff wurde erbeten.

EWOULDBLOCK
Der Schalter O_NONBLOCK wurde angegeben und eine inkompatible Ausleihe wurde auf
der Datei gehalten (siehe fcntl(2)).

Die folgenden zusätzlichen Fehler können bei openat() auftreten:

EBADF dirfd ist kein zulässiger Dateideskriptor.

ENOTDIR
pathname ist ein relativer Pfadname und dirfd ist ein Dateideskriptor, der sich auf
eine Datei statt auf ein Verzeichnis bezieht.

VERSIONEN

       openat() wurde zu Linux in Kernel 2.6.16 hinzugefügt;  Bibliotheksunterstützung  wurde  zu
       Glibc in Version 2.4 hinzugefügt.

KONFORM ZU

       open(), creat()  SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.

       openat(): POSIX.1-2008.

       Die  Schalter  O_DIRECT, O_NOATIME, O_PATH und O_TMPFILE sind Linux-spezifisch. Sie müssen
       _GNU_SOURCE definieren, um ihre Definitionen zu erhalten.

       Die Schalter O_CLOEXEC, O_DIRECTORY und O_NOFOLLOW sind nicht in POSIX.1-2001  sondern  in
       POSIX.1-2008  spezifiziert.  Seit  Glibc  2.12 kann ihre Definition erhalten werden, indem
       entweder _POSIX_C_SOURCE mit einem Wert größer als oder  identisch  zu  200809L  definiert
       wird  oder  durch  _XOPEN_SOURCE mit einem Wert größer als oder identisch zu 700. In Glibc
       2.11 und älter kann die Definition über die Definition von _GNU_SOURCE erhalten werden.

       Wie in feature_test_macros(7) angemerkt, müssen Feature-Test-Makros  wie  _POSIX_C_SOURCE,
       _XOPEN_SOURCE   und  _GNU_SOURCE  definiert  werden,  bevor  irgendeine  Header-Datei  mit
       »include« verwandt wird.

ANMERKUNGEN

Unter Linux wird der Schalter O_NONBLOCK manchmal in Fällen benutzt, in denen die Datei
geöffnet werden soll, ohne aber notwendigerweise zu lesen oder zu schreiben.
Beispielsweise kann dies dazu verwandt werden, ein Gerät zu öffnen, um einen
Dateideskriptor für ioctl(2) zu erhalten.

Der (undefinierte) Effekt von O_RDONLY | O_TRUNC unterscheidet sich in vielen
Implementierungen. Auf vielen Systemen wird die Datei tatsächlich abgeschnitten.

Beachten Sie, dass open() Spezial-Gerätedateien öffnen kann, aber creat() sie nicht
erstellen kann. Verwenden Sie stattdessen mknod(2).

Falls die Datei neu erstellt wurde, werden ihre Felder st_atime, st_ctime, st_mtime (Zeit
des letzten Zugriffs, Zeit der letzten Statusänderung und Zeit der letzten Änderung, siehe
stat(2)) auf die aktuelle Zeit gesetzt und ebenso die Felder st_ctime und st_mtime des
Elternverzeichnisses. Andernfalls, falls die Datei aufgrund des Schalters O_TRUNC geändert
wurde, werden ihre Felder st_ctime und st_mtime auf die aktuelle Zeit gesetzt.

Die Dateien im Verzeichnis /proc/[PID]/fd zeigen die offenen Dateideskriptoren des
Prozesses mit der PID PID. Die Dateien im Verzeichnis /proc/[PID]/fdinfo zeigen noch mehr
Informationen über diese Dateideskriptoren. Siehe proc(5) für weitere Details über beide
Verzeichnisse.

Die Linux-Header-Datei <asm/fcntl.h> definiert O_ASYNC nicht, es wird stattdessen das (von
BSD abgeleitete) Synonym FASYNC definiert.

Offene Dateideskriptionen:
Der Begriff offene Dateideskription wird von POSIX verwandt, um sich auf Einträge in der
systemweiten Tabelle der offenen Dateien zu beziehen. In anderen Zusammenhängen wird
dieses Objekt verschieden auch »offenes Dateiobjekt«, »Datei-Handle«, »offener
Dateitabelleneintrag« oder – in der Sprache der Kernel-Entwickler – struct file genannt.

Wenn ein Dateideskriptor (mit dup(2) oder ähnlichem) dupliziert wird, bezieht sich das
Duplikat auf die gleiche offene Dateideskription wie der ursprüngliche Datedeskriptor und
die zwei Dateideskriptoren haben konsequenterweise den gleichen Dateiversatz und die
gleichen Dateistatusschalter. Solch ein gemeinsamer Satz kann auch zwischen Prozessen
auftreten: ein mit fork(2) erstellter Kindprozess erbt Duplikate der Dateideskriptoren
seines Elternprozesses und diese Duplikate beziehen sich auf die gleichen offenen
Dateideskriptoren.

Jedes open() einer Datei erstellt eine neue offene Dateideskription; daher kann es mehrere
offene Dateideskriptionen geben, die einem Datei-Inode entsprechen.

Unter Linux kann die Aktion KCMP_FILE von kcmp(2) zum Testen, ob sich zwei
Dateideskriptoren (in dem gleichen Prozess oder in zwei verschiedenen Prozessen) auf die
gleiche offene Dateideskription beziehen, verwandt werden.

Synchronisierte E/A
Die Option »synchronisierte E/A« von POSIX.1-2008 spezifiziert verschiedene Varianten der
synchronisierten E/A und spezifiziert Schalter O_SYNC, O_DSYNC und O_RSYNC von open() für
die Steuerung des Verhaltens. Unabhängig davon, ob eine Implementierung diese Option
unterstützt muss sie mindestens die Verwendung von O_SYNC für reguläre Dateien
unterstützen.

Linux implementiert O_SYNC und O_DSYNC, aber nicht O_RSYNC. Etwas inkorrekt definiert
Glibc O_RSYNC auf den gleichen Wert wie O_SYNC. (O_RSYNC wird auf HP PA-RISC in der
Linux-Header-Datei <asm/fcntl.h> definiert aber nicht benutzt.)

O_SYNC stellt synchronisierte E/A-Datei-Integritätsvervollständigung bereit. Das bedeutet,
Schreibaktionen schieben ihre Daten und zugehörigen Metadaten an die darunterliegende
Hardware. O_DSYNC stellt synchronisierte E/A-Daten-Integritätsvervollständigung bereit.
Das bedeutet, Schreibaktionen schieben ihre Daten an die darunterliegende Hardware, aber
schieben nur Metadatenaktualisierungen, die benötigt werden, um folgende Leseaktionen
erfolgreich abzuschließen. Datenintegritätsvervollständigung kann die Anzahl der Aktionen
reduzieren, die für Anwendungen notwendig werden, die keine Garantien für die
Dateiintegritätsvervollständigung benötigen.

Um den Unterschied zwischen den zwei Arten von Vervollständigung zu verstehen, betrachen
Sie zwei verschiedene Dateimetadaten: den Zeitstempel der letzten Änderung (st_mtime) und
die Dateilänge. Alle Schreibaktionen aktualisieren den Zeitstempel der letzten
Dateiänderung, aber nur Schreibaktionen, die Daten am Ende der Datei hinzufügen, müssen
die Dateilänge ändern. Der Zeitstempel der letzten Änderung wird nicht benötigt, um
sicherzustellen, dass eine Leseaktion erfolgreich abgeschlossen werden kann, aber die
Dateilänge wird dafür benötigt. Daher würde O_DSYNC nur garantieren, dass Aktualisierungen
der Dateilängen-Metadaten rausgeschoben werden (während O_SYNC immer auch das Metadatum
des Zeitstempels der letzten Änderung rausschieben würde).

Vor Linux 2.6.33 implementierte Linux nur den Schalter O_SYNC für open(). Als dieser
Schalter spezifiziert wurde, stellten die meisten Dateisysteme das Äquivalent von
synchronisierter E/A-Daten-Integritätsvervollständigung bereit (d.h. O_SYNC war
tatsächlich als Äquivalent von O_DSYNC implementiert).

Seit Linux 2.6.33 wird korrekte Unterstützung für O_SYNC bereitgestellt. Um
Rückwärtskompatibilität sicherzustellen wurde aber O_DSYNC mit dem gleichen Wert wie das
historische O_SYNC definiert und O_SYNC wurde als neuer (Zweibit-)Schalterwert definiert,
der den Wert des Schalters O_DSYNC enthält. Das stellt sicher, dass Anwendungen, die gegen
neue Header übersetzt wurden, mindestens die Semantik von O_DSYNC auf pre-2.6.33-Kerneln
erhalten.

Unterschiede C-Bibliothek/Kernel
Seit Version 2.26 setzt die Glibc-Wrapper-Funktion für open() den Systemaufruf openat()
statt des Systemaufrufs open() des Kernels ein. Für bestimmte Architekturen stimmt dies
auch für Glibc-Versionen vor 2.26.

NFS
Es gibt mehrere Unglücklichkeiten im Protokoll, das NFS unterliegt, die unter anderem
O_SYNC und O_NDELAY betreffen.

Auf NFS-Dateisystemen mit aktivierter UID-Abbildung könnte open() einen Dateideskriptor
zurückliefern, aber read(2)-Anfragen werden beispielsweise mit EACCES verweigert. Dies
erfolgt, da der Client open() durchführt, indem er die Rechte prüft, aber die
UID-Abbildung auf dem Server bei Lese- und Schreibanfragen erfolgt.

FIFOs
Öffnen des Lese- oder Schreibendes eines FIFOS blockiert, bis das andere Ende auch
geöffnet wurde (durch einen anderen Prozess oder Thread). Siehe fifo(7) für weitere
Details.

Dateizugriffsmodus
Anders als andere Werte, die in flags festgelegt werden können, legen die
Zugriffsmodus-Werte O_RDONLY, O_WRONLY und O_RDWR nicht individuelle Bits fest.
Stattdessen definieren sie die untersten zwei Bits von flags und sind respektive als 0, 1
und 2 definiert. Mit anderen Worten, die Kombination O_RDONLY | O_WRONLY ist ein logischer
Fehler und hat bestimmt nicht die gleiche Bedeutung wie O_RDWR.

Linux reserviert den besonderen, nicht standardisierten Zugriffsmodus 3 (binär 11) in
flags für folgendes: Prüfe auf Lese- und Schreibberechtigung der Datei und liefere einen
Dateideskriptor zurück, der weder zum Lesen noch zum Schreiben verwandt werden kann.
Dieser nicht standardisierte Zugriffsmodus wird von einigen Linux-Treibern verwandt, um
einen Dateideskriptor zurückzuliefern, der nur für gerätespezifische ioctl(2)-Aktionen
benutzt werden kann.

Begründung für openat()- und andere Verzeichnis-Dateideskriptor APIs
openat() und andere Systemaufrufe und Bibliotheksfunktionen, die ein
Verzeichnis-Dateideskriptor als Argument akzeptieren (d.h. execveat(2), faccessat(2),
fanotify_mark(2), fchmodat(2), fchownat(2), fstatat(2), futimesat(2), linkat(2),
mkdirat(2), mknodat(2), name_to_handle_at(2), readlinkat(2), renameat(2), statx(2),
symlinkat(2), unlinkat(2), utimensat(2), mkfifoat(3) und scandirat(3)) behandeln zwei
Probleme mit der älteren Schnittstelle, die dieser voranging. Hier erfolgt die Erläuterung
am openat()-Aufruf, aber der Grund ist analog für die anderen Schnittstellen.

Erstens erlaubt openat() es Anwendungen, Race-Conditions zu vermeiden, die bei der
Verwendung von open() auftreten können, wenn Dateien geöffnet werden, die sich nicht im
lokalen Verzeichnis befinden. Diese Race-Conditions entstammen der Tatsache, dass einige
Komponenten des Verzeichnispräfixes, der an open() übergeben wird, parallel zum Aufruf von
open() geändert werden können. Nehmen Sie beispielsweise an, dass Sie die Datei
dir1/dir2/xxx.dep öffnen möchten, falls dir1/dir2/xxx existiert. Das Problem besteht
darin, das sich zwischen der Existenzüberprüfung und dem Schritt der Dateierstellung dir1
oder dir2 (die symbolischen Links sein können) geändert haben und auf einen anderen Ort
zeigen können. Solche Ressourcenwettläufe können vermieden werden, indem ein
Dateideskriptor für das Zielverzeichnis geöffnet wird und dann dieser Dateideskriptor als
Argument dirfd von (beispielsweise) fstatat(2) und openat() verwandt wird. Die Verwendung
des Dateideskriptors dirfd hat auch weitere Vorteile:

* Der Dateideskriptor ist eine stabile Referenz zu dem Verzeichnis, selbst falls das
Verzeichnis umbenannt wird.

* Der offene Dateideskriptor verhindert, dass das darunterliegende Dateisystem ausgehängt
wird, genauso als wenn ein Prozess sein aktuelles Arbeitsverzeichnis auf dem
Dateisystem hat.

Zweitens erlaubt openat() die Implementierung eines pro-Thread-»Arbeitsverzeichnisses«,
mittels von der Anwendung verwalteten Datei-Deskriptor(en). (Diese Funktionalität kann
weniger effizient auch mittels Tricks basierend auf der Verwendung von /proc/self/fd/dirfd
erreicht werden.)

O_DIRECT
Der Schalter O_DIRECT könnte Ausrichtungsbeschränkungen in der Länge und Adresse der
Puffer in der Anwendungsebene und dem Dateiversatz von E/As verhängen. Unter Linux
variieren die Ausrichtungsbeschränkungen je nach Dateisystem und Kernelversion und können
auch ganz fehlen. Es gibt jedoch derzeit keine dateisystemunabhängige Schnittstelle für
eine Anwendung, um diese Beschränkungen für eine gegebene Datei oder ein Dateisystem
aufzufinden. Einige Dateisysteme stellen zu diesem Zweck ihre eigenen Schnittstellen
bereit, beispielsweise die Aktion XFS_IOC_DIOINFO in xfsctl(3).

Unter Linux 2.4 müssen Übertragungsgrößen, die Ausrichtung des Benutzerpuffers und der
Dateiversatz Vielfache der logischen Blockgröße des Dateisystems sein. Seit Linux 2.6.0
reicht ein Ausrichtung an der logischen Blockgröße des darunterliegenden Speichers
(normalerweise 512 byte) aus. Die logische Blockgröße kann mit der Aktion BLKSSZGET von
ioctl(2) festgelegt werden oder mittels des Shell-Befehls:

blockdev --getss

O_DIRECT I/Os should never be run concurrently with the fork(2) system call, if the memory
buffer is a private mapping (i.e., any mapping created with the mmap(2) MAP_PRIVATE flag;
this includes memory allocated on the heap and statically allocated buffers). Any such
I/Os, whether submitted via an asynchronous I/O interface or from another thread in the
process, should be completed before fork(2) is called. Failure to do so can result in
data corruption and undefined behavior in parent and child processes. This restriction
does not apply when the memory buffer for the O_DIRECT I/Os was created using shmat(2) or
mmap(2) with the MAP_SHARED flag. Nor does this restriction apply when the memory buffer
has been advised as MADV_DONTFORK with madvise(2), ensuring that it will not be available
to the child after fork(2).

Der Schalter O_DIRECT wurde in SGI IRIX eingeführt, wo er Ausrichtungsbeschränkungen hat,
die denen von Linux 2.4 ähnlich sind. IRIX hat außerdem einen fcntl(2)-Aufruf, um
geeignete Ausrichtungen und Größen abzufragen. FreeBSD 4.x führte einen gleichnamigen
Schalter ein, jedoch ohne Ausrichtungsbeschränkungen.

Die Unterstützung für O_DIRECT wurde unter Linux in Kernel Version 2.4.10 hinzugefügt.
Ältere Kernel werden diesen Schalter einfach ignorieren. Einige Dateisysteme könnten den
Schalter nicht implementieren. In diesem Fall schlägt open() mit dem Fehler EINVAL fehl,
falls er verwandt wird.

Anwendungen sollten das Vermischen von O_DIRECT und normaler E/A auf der gleichen Datei
vermeiden, insbesondere für überlappende Regionen in der gleichen Datei. Selbst wenn das
Dateisystem die Kohärenzprobleme in dieser Situation korrekt handhabt, ist der
Gesamt-E/A-Durchsatz wahrscheinlich geringer, als wenn einer der beiden Modi allein
verwandt worden wäre. Entsprechend sollten Anwendungen das Mischen von mmap(2) von Dateien
mit direktem E/A auf die gleichen Dateien vermeiden.

Das Verhalten von O_DIRECT mit NFS wird sich vom lokalen Dateisystem unterscheiden. Ältere
Kernel oder Kernel, die in bestimmter Weise konfiguriert wurden, unterstützen diese
Kombination möglicherweise nicht. Das NFS-Protokoll unterstützt die Übergabe des Schalters
an den Server nicht, daher wird O_DIRECT-E/A den Seitenzwischenspeicher auf dem Client
umgehen. Der Server könnte weiterhin die E/A zwischenspeichern. Der Client bittet den
Server, die E/A zu synchronisieren, damit die synchrone Semantik von O_DIRECT
aufrechterhalten wird. Einige Server werden unter diesen Umständen unzureichende Leistung
erbringen, insbesondere bei kleiner E/A-Größe. Einige Server sind möglicherweise auch so
konfiguriert, dass sie ihre Clients darüber belügen, dass die E/A stabilen Speicher
erreicht haben. Dies wird die Leistungseinbuße bei gleichzeitigem Risiko der
Datenintegrität im Fall eines Stromausfalls verhindern. Der Linux-NFS-Client legt keine
Ausrichtungsbeschränkungen bei O_DIRECT-E/A fest.

In Zusammenfassung: O_DIRECT ist ein extrem leistungsfähiges Werkzeug, das mit Vorsicht
verwandt werden sollte. Es wird empfohlen, dass Anwendungen die Verwendung von O_DIRECT
als Leistungssteigerungsoption betrachten, die standardmäßig deaktiviert ist.

FEHLER

       Derzeit  ist  es  nicht  möglich,  Signal-getriebene E/A zu aktivieren, indem O_ASYNC beim
       Aufruf von open() verwandt wird; siehe fcntl(2), um diesen Schalter zu aktivieren.

       Es muss auf zwei  verschiedene  Fehler-Codes,  EISDIR  und  ENOENT  geprüft  werden,  wenn
       versucht wird, zu bestimmen, ob der Kernel die Funktionalität O_TMPFILE unterstützt.

       Wenn  sowohl  O_CREAT  als auch O_DIRECTORY in flags angegeben sind und die durch pathname
       angegebene  Datei  nicht  existiert,  wird  open()  eine  normale  Datei  erstellen  (d.h.
       O_DIRECTORY wird ignoriert).

SIEHE AUCH

       chmod(2),  chown(2),  close(2),  dup(2),  fcntl(2),  link(2), lseek(2), mknod(2), mmap(2),
       mount(2),  open_by_handle_at(2),  read(2),  socket(2),   stat(2),   umask(2),   unlink(2),
       write(2), fopen(3), acl(5), fifo(7), inode(7), path_resolution(7), symlink(7)

KOLOPHON

       Diese  Seite  ist  Teil  der  Veröffentlichung  5.03  des  Projekts  Linux-man-pages. Eine
       Beschreibung des Projekts, Informationen, wie Fehler  gemeldet  werden  können  sowie  die
       aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die    deutsche   Übersetzung   dieser   Handbuchseite   wurde   von   Mario   Blättermann
       <mario.blaettermann@gmail.com>, Chris Leick  <c.leick@vollbio.de>,  Dr.  Tobias  Quathamer
       <toddy@debian.org> und Helge Kreutzmann <debian@helgefjell.de> 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 <debian-l10n-german@lists.debian.org>.