Provided by: manpages-de-dev_4.21.0-2_all 
BEZEICHNUNG
open, openat, creat - eine Datei öffnen und möglicherweise erzeugen
BIBLIOTHEK
Standard-C-Bibliothek (libc, -lc)
ÜBERSICHT
#include <fcntl.h>
int open(const char *Pfadname, int Schalter);
int open(const char *Pfadname, int Schalter, mode_t Modus);
int creat(const char *Pfadname, mode_t Modus);
int openat(int Verzdd, const char *Pfadname, int Schalter);
int openat(int Verzdd, const char *Pfadname, int Schalter, mode_t Modus);
/* Separat in openat2(2) dokumentiert: */
int openat2(int Verzdd, const char *Pfadname,
const struct open_how *wie, size_t Größe);
Mit Glibc erforderliche Feature-Test-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 Pfadname angegebene Datei. Falls die angegebene Datei nicht
existiert, kann sie optional (falls O_CREAT in Schalter angegeben wurde) durch open() erstellt werden.
Der Rückgabewert von open() ist ein Dateideskriptor, eine kleine, nicht negative Ganzzahl, die ein Index
für einen Eintrag in der Tabelle der offenen Dateideskriptoren des Prozesses ist. Der Dateideskriptor
wird in nachfolgenden Systemaufrufen (read(2), write(2), lseek(2), fcntl(2) usw.) genutzt, 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 Pfadname 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 Schalter 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 Schalter 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 Angabe 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 Pfadname 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 Modus gibt die Dateimodusbits, die beim Erstellen einer neuen Dateien angewandt
werden sollen, an. Falls weder O_CREAT noch O_TMPFILE angegeben ist, wird Modus ignoriert (und
kann daher als 0 angegeben oder einfach weggelassen werden). Das Argument Modus muss angegeben
werden, falls O_CREAT oder O_TMPFILE in Schalter angegeben ist; wird es nicht angegeben, werden
einige willkürliche Bytes aus dem Stack als Dateimodus gesetzt.
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 les- und
schreibbaren Dateideskriptor zurückliefern.
Für Modus 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 Modus gesetzt werden, nicht spezifiziert. Unter
Linux werden auch die folgenden Bits in Modus 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 missbilligte) Schnittstelle für Blockgeräte wird in raw(8)
beschrieben.
O_DIRECTORY
Falls Pfadname kein Verzeichnis ist, schlägt damit open fehl. Dieser Schalter wurde in
Linux-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
angegeben wird und Pfadname bereits existiert, dann schlägt open() mit dem Fehler EEXIST fehl.
Wenn diese zwei Schalter angegeben werden, wird symbolischen Links nicht gefolgt. Falls Pfadname
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
Pfadname 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 Pfadname 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 die abschließende Komponenten (d.h. der Basisname) von Pfadname 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 Verzdd 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 Schalter 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 Pfadname 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 Verzdd 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 Pfadname 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 Pfadname gibt ein Verzeichnis an;
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«… */
linkat(fd, "", AT_FDCWD, "/Pfad/zur/Datei", AT_EMPTY_PATH);
/* Falls der Aufrufende nicht über die Capability CAP_DAC_READ_SEARCH
verfügt (benötigt, um AT_EMPTY_PATH mit linkat(2) zu verwenden) und ein
proc(5)-Dateisystem eingehängt ist, dann kann obiger linkat(2)-Aufruf
mit Folgendem ersetzt werden:
snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd);
linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
AT_SYMLINK_FOLLOW);
*/
In diesem Fall bestimmt das Argument Modus 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 Tmpfs 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 Schalter identisch zu
O_CREAT|O_WRONLY|O_TRUNC.
openat()
Der Systemaufruf openat() arbeitet genau wie open(), außer den hier beschriebenen Unterschieden.
Das Verzdd-Argument wird in Verbindung mit dem Pfadname-Argument wie folgt verwendet:
• Falls der in Pfadname übergebene Pfadname absolut ist, wird Verzdd ignoriert.
• Falls der angegebene Pfadname relativ ist und Verzdd den speziellen Wert AT_FDCWD enthält, dann wird
Pfadname relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie
open()).
• Falls der in Pfadname angegebene Pfadname relativ ist, dann wird er relativ zu dem Verzeichnis
interpretiert, auf das der Dateideskriptor Verzdd verweist (statt relativ zu dem aktuellen
Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei open() für einen relativen Pfadnamen
erfolgt). In diesem Fall muss Verzdd ein Verzeichnis sein, das zum Lesen geöffnet wurde, oder den
Schalter O_PATH vewenden.
Falls der angegebene Pfadname relativ und Verzdd kein gültiger Dateideskriptor ist, wird ein Fehler
(EBADF) ausgegeben. (Die Angabe einer ungültigen Dateideskriptornummer in Verzdd kann dazu verwendet
werden, um sicherzustellen, dass der Pfadname absolut ist.)
openat2(2)
Der Systemaufruf openat2(2) ist eine Erweiterung von openat() und stellt eine Obermenge der
Funtionalitäten von openat() zur Verfügung. Er ist separat in openat2(2) dokumentiert.
RÜCKGABEWERT
open(), openat() und creat() liefern bei Erfolg den neuen Dateideskriptor zurück (eine nicht negative
Ganzzahl) oder -1, falls ein Fehler auftrat (in diesem Fall wird errno gesetzt, um den Fehler
anzuzeigen).
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 Pfadname verweigert oder die Datei existierte noch nicht oder
Schreibzugriff auf das Elternverzeichnis ist nicht erlaubt. (Siehe auch path_resolution(7).)
EACCES Ist O_CREAT angegeben, dann ist der protected_fifos- oder protected_regular-Sysctl aktiviert, die
Datei existiert bereits und ist ein FIFO oder eine reguläre Datei, der Eigentümer der Datei ist
weder der aktuelle Benutzer noch der Eigentümer des enthaltenden Verzeichnisses und das
enthaltende Verzeichnis ist sowohl durch alle als auch durch die Gruppe schreibbar und »sticky«.
Für Details siehe die Beschreibung von /proc/sys/fs/protected_fifos und
/proc/sys/fs/protected_regular in proc(5).
EBADF (openat()) Der Pfadname ist relativ, aber Verzdd ist weder AT_FDCWD noch ein gültiger
Dateideskriptor.
EBUSY O_EXCL wurde in Schalter angegeben und Pfadname bezieht sich auf ein blockorientiertes Gerät, das
vom System verwendet wird (zum Beispiel, wenn es eingehängt ist).
EDQUOT Wo O_CREAT angegeben ist existiert die Datei nicht und das Kontingent des Benutzers an
Plattenblöcken oder Inodes auf dem Dateisystem ist erschöpft.
EEXIST Pfadname existiert bereits und O_CREAT und O_EXCL wurden verwandt.
EFAULT Pfadname 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 Schalter angegeben, aber weder O_WRONLY noch O_RDWR wurden angegeben.
EINVAL O_CREAT wurde in Schalter angegeben und die abschließende Komponente (»basename«) des Pfadname der
neuen Datei ist ungültig (d.h. sie enthält im unterliegenden Dateisystem nicht erlaubte Zeichen).
EINVAL Die abschließende Komponente (»basename«) des Pfadnames ist ungültig (d.h. sie enthält im
unterliegenden Dateisystem nicht erlaubte Zeichen).
EISDIR Pfadname bezieht sich auf ein Verzeichnis und der Zugriff beinhaltete Schreiben (d.h. O_WRONLY
oder O_RDWR ist gesetzt).
EISDIR Pfadname bezieht sich auf ein existierendes Verzeichnis, O_TMPFILE und entweder O_WRONLY oder
O_RDWR wurde in Schalter angegeben, aber diese Kernelversion stellt die Funktionalität O_TMPFILE
nicht zur Verfügung.
ELOOP Bei der Auflösung von Pfadname wurden zu viele symbolische Links gefunden.
ELOOP Pfadname war ein symbolischer Link und Schalter 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
Pfadname war zu lang.
ENFILE Die systemweite Beschränkung für die Gesamtzahl offener Dateien wurde erreicht.
ENODEV Pfadname 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 Pfadname existiert nicht oder ist ein toter symbolischer Link.
ENOENT Pfadname bezieht sich auf ein nicht existierendes Verzeichnis, O_TMPFILE und entweder O_WRONLY
oder O_RDWR wurde in Schalter 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 Pfadname sollte erstellt werden, aber das Gerät, das Pfadname enthält, hat für die neue Datei
keinen Platz.
ENOTDIR
Eine als Verzeichnis verwandte Komponente in Pfadname ist tatsächlich kein Verzeichnis oder
O_DIRECTORY wurde angegeben, aber Pfadname war kein Verzeichnis.
ENOTDIR
(openat()) Pfadname ist ein relativer Pfadname und Verzdd ist ein Dateideskriptor, der sich auf
eine Datei statt auf ein Verzeichnis bezieht.
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 Pfadname enthält, unterstützt O_TMPFILE nicht.
EOVERFLOW
Pfadname 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 Versionen vor 2.6.24 gab Linux in
diesem Fall den Fehler EFBIG zurück.
EPERM Der Schalter O_NOATIME war angegeben, 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 Pfadname bezieht sich auf eine Datei auf einem schreibgeschützten Dateisystem, und Schreibzugriff
wurde angefordert.
ETXTBSY
Pfadname bezieht sich auf ein ausführbares Abbild, das derzeit ausgeführt wird und Schreibzugriff
wurde erbeten.
ETXTBSY
Pfadname bezieht sich auf eine Datei, die derzeit als Auslagerungsdatei verwandt wird und O_TRUNC
wurde festgelegt.
ETXTBSY
Pfadname bezieht sich auf eine 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)).
VERSIONEN
openat() wurde zu Linux in Version 2.6.16 hinzugefügt; Bibliotheksunterstützung wurde zu Glibc in Version
2.4 hinzugefügt.
STANDARDS
open(), creat() SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
openat(): POSIX.1-2008.
openat2(2) ist Linux-spezifisch.
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
Linux vor 2.6.33 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 Schalter angegeben 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
Schalter 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 Schalter 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),
fspick(2), fstatat(2), futimesat(2), linkat(2), mkdirat(2), mknodat(2), mount_setattr(2), move_mount(2),
name_to_handle_at(2), open_tree(2), openat2(2), readlinkat(2), renameat(2), renameat2(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 Verzdd von (beispielsweise) fstatat(2) und openat()
verwandt wird. Die Verwendung des Dateideskriptors Verzdd 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/Verzdd erreicht werden.)
Das Argument Verzdd für diese APIs kann mittels open() oder openat() zum Öffnen eines Verzeichnisses
erhalten werden (mit entweder dem Schalter O_RDONLY oder O_PATH). Alternativ kann ein solcher
Dateideskriptor durch Anwendung von dirfd(3) auf einen mittels opendir(3) erzeugten Verzeichnisdatenstrom
erhalten werden.
Wird diesen APIs ein Verzdd-Argument von AT_FDCWD übergeben oder der angegebene Pfadname ist absolut,
dann handhaben sie ihr Pfadnamenargument auf die gleiche Art wie entsprechende konventionelle APIs. In
diesem Fall haben allerdings mehrere der APIs das Argument Schalter, das Zugriff auf die Funktionalität
gewährt, die mit den entsprechenden konventionellen APIs nicht verfügbar ist.
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. Der Umgang
mit nicht ausgerichtetem O_DIRECT-E/A unterscheidet sich auch; er kann entweder mit EINVAL fehlschlagen
oder auf gepufferten E/A ausweichen.
Seit Linux 6.1 können die Unterstützung für O_DIRECT und Ausrichtungsbeschränkungen für eine Datei
mittels statx(2) unter Verwendung des Schalters STATX_DIOALIGN abgefragt werden. Die Unterstützung für
STATX_DIOALIGN unterscheidet sich je nach Dateisystem; siehe statx(2).
Einige Dateisysteme stellen ihre eigene Schnnittstelle zur Abfrage von
O_DIRECT-Ausrichtungsbeschränkungen bereit. Wenn verfügbar, sollte STATX_DIOALIGN stattdessen verwendet
werden.
Falls keines der obigen verfügbar ist, dann können die Unterstützung für direkte E/A und
Ausrichtungsbeschränkungen nur von bekannten Charakteristika des Dateisystems, der einzelnen Datei, des
oder der zugrunde liegenden Speichergeräte und der Kernelversion abgeschätzt werden. In Linux 2.4
benötigten die meisten auf Blockgeräten basierenden Dateisysteme, dass der Dateiversatz und die Länge und
Speicheradresse sämtlicher E/A-Segmente Vielfaches der Dateisystemblockgröße (typischerweise 4096 byte)
sind. In Linux 2.6.0 wurde dies auf die logische Blockgröße des Blockgerätes (typischerweise 512 byte)
gelockert. Die logische Blockgröße eines Blockgerätes kann mit der Aktion ioctl(2) BLKSSZGET oder von der
Shell mittels folgendem Befehl ermittelt werden:
blockdev --getss
O_DIRECT-E/As sollten niemals gleichzeitig mit dem Systemaufruf fork(2) ausgeführt werden, falls der
Speicherpuffer ein privates Mapping ist (das heißt, jede mit dem Schalter MAP_PRIVATE von mmap(2)
erzeugtes Mapping; dies beinhaltet im Heap zugewiesenen Speicher und statisch zugewiesene Puffer). Und
solche E/As, ganz gleich ob über eine asynchrone E/A-Schnittstelle oder über einen anderen Thread im
Prozess übergeben, sollten abgeschlossen sein, bevor fork(2) aufgerufen wird. Tun Sie dies nicht, kann
Beschädigung von Daten und undefiniertes Verhalten in Eltern- und Kindprozessen die Folge sein. Diese
Einschränkung gilt nicht, wenn der Speicherpuffer für die O_DIRECT-E/As mittels shmat(2) oder mmap(2) mit
dem Schalter MAP_SHARED erzeugt wurde. Außerdem gilt die Einschränkung nicht, wenn der Speicherpuffer mit
madvise(2) als MADV_DONTFORK deklariert wurde, was sicherstellt, dass es nach dem Aufruf von fork(2) für
den Kindprozess nicht verfügbar ist.
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 Version 2.4.10 hinzugefügt. Ältere Linux-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 Schalter angegeben sind und die durch Pfadname 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), openat2(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)
Ü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
⟨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⟩.