.\" -*- coding: UTF-8 -*- .\" This manpage is Copyright (C) 1992 Drew Eckhardt; .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson. .\" and Copyright (C) 2008 Greg Banks .\" and Copyright (C) 2006, 2008, 2013, 2014 Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" Modified 1993-07-21 by Rik Faith .\" Modified 1994-08-21 by Michael Haardt .\" Modified 1996-04-13 by Andries Brouwer .\" Modified 1996-05-13 by Thomas Koenig .\" Modified 1996-12-20 by Michael Haardt .\" Modified 1999-02-19 by Andries Brouwer .\" Modified 1998-11-28 by Joseph S. Myers .\" Modified 1999-06-03 by Michael Haardt .\" Modified 2002-05-07 by Michael Kerrisk .\" Modified 2004-06-23 by Michael Kerrisk .\" 2004-12-08, mtk, reordered flags list alphabetically .\" 2004-12-08, Martin Pool (& mtk), added O_NOATIME .\" 2007-09-18, mtk, Added description of O_CLOEXEC + other minor edits .\" 2008-01-03, mtk, with input from Trond Myklebust .\" and Timo Sirainen .\" Rewrite description of O_EXCL. .\" 2008-01-11, Greg Banks : add more detail .\" on O_DIRECT. .\" 2008-02-26, Michael Haardt: Reorganized text for O_CREAT and mode .\" .\" FIXME . Apr 08: The next POSIX revision has O_EXEC, O_SEARCH, and .\" O_TTYINIT. Eventually these may need to be documented. --mtk .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH open 2 "2. Mai 2024" "Linux man\-pages 6.8" .SH BEZEICHNUNG open, openat, creat \- eine Datei öffnen und möglicherweise erzeugen .SH BIBLIOTHEK Standard\-C\-Bibliothek (\fIlibc\fP, \fI\-lc\fP) .SH ÜBERSICHT .nf \fB#include \fP .P \fBint open(const char *\fP\fIPfadname\fP\fB, int \fP\fISchalter\fP\fB, …\fP \fB \fP/*\fB mode_t \fP\fIModus\fP\fB \fP*/\fB );\fP .P \fBint creat(const char *\fP\fIPfadname\fP\fB, mode_t \fP\fIModus\fP\fB);\fP .P \fBint openat(int \fP\fIVerzdd\fP\fB, const char *\fP\fIPfadname\fP\fB, int \fP\fISchalter\fP\fB, …\fP \fB \fP/*\fB mode_t \fP\fIModus\fP\fB \fP*/\fB );\fP .P /* Separat in \fBopenat2\fP(2) dokumentiert:\& */ \fBint openat2(int \fP\fIVerzdd\fP\fB, const char *\fP\fIPfadname\fP\fB,\fP \fB const struct open_how *\fP\fIwie\fP\fB, size_t \fP\fIGröße\fP\fB);\fP .fi .P .RS -4 Mit Glibc erforderliche Feature\-Test\-Makros (siehe \fBfeature_test_macros\fP(7)): .RE .P \fBopenat\fP(): .nf Seit Glibc 2.10: _POSIX_C_SOURCE >= 200809L Vor Glibc 2.10: _ATFILE_SOURCE .fi .SH BESCHREIBUNG Der Systemaufruf \fBopen\fP() öffnet eine durch \fIPfadname\fP angegebene Datei. Falls die angegebene Datei nicht existiert, kann sie optional (falls \fBO_CREAT\fP in \fISchalter\fP angegeben wurde) durch \fBopen\fP() erstellt werden. .P Der Rückgabewert von \fBopen\fP() 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 (\fBread\fP(2), \fBwrite\fP(2), \fBlseek\fP(2), \fBfcntl\fP(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. .P Standardmäßig bleibt der neue Dateideskriptor über ein \fBexecve\fP(2) offen (d.h. der in \fBfcntl\fP(2) beschriebene Dateideskriptorschalter \fBFD_CLOEXEC\fP ist anfangs leer). Der weiter unten beschriebene Schalter \fBO_CLOEXEC\fP kann zum Ändern dieser Vorgabe verwandt werden. Der Dateiversatz wird auf den Anfang der Datei gesetzt (siehe \fBlseek\fP(2)). .P Ein Aufruf von \fBopen\fP() erstellt eine neue \fIoffene Dateideskription\fP, 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 \fIPfadname\fP im Folgenden entfernt oder so verändert wird, dass er auf eine andere Datei zeigt. Für weitere Details über offene Dateideskriptionen, siehe ANMERKUNGEN. .P Das Argument \fISchalter\fP muss einen der folgenden \fIZugriffsmodi\fP enthalten: \fBO_RDONLY\fP, \fBO_WRONLY\fP oder \fBO_RDWR\fP. Diese erbitten, die Datei nur lesbar, nur schreibbar bzw. les\-/schreibbar zu öffnen. .P .\" SUSv4 divides the flags into: .\" * Access mode .\" * File creation .\" * File status .\" * Other (O_CLOEXEC, O_DIRECTORY, O_NOFOLLOW) .\" though it's not clear what the difference between "other" and .\" "File creation" flags is. I raised an Aardvark to see if this .\" can be clarified in SUSv4; 10 Oct 2008. .\" http://thread.gmane.org/gmane.comp.standards.posix.austin.general/64/focus=67 .\" TC1 (balloted in 2013), resolved this, so that those three constants .\" are also categorized" as file status flags. .\" Zusätzlich können Null oder mehr Dateierstellungsschalter in \fISchalter\fP mit einem bitweisen \fIODER\fP zusammengebracht werden. Die \fIDateierstellungsschalter\fP sind \fBO_CLOEXEC\fP, \fBO_CREAT\fP, \fBO_DIRECTORY\fP, \fBO_EXCL\fP, \fBO_NOCTTY\fP, \fBO_NOFOLLOW\fP, \fBO_TMPFILE\fP und \fBO_TRUNC\fP. Die restlichen unten aufgeführten Schalter sind die \fIDateistatusschalter\fP. 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 \fBfcntl\fP(2) für Details. .P Die komplette Liste der Dateierstellungs\- und Dateistatusschalter ist wie folgt: .TP \fBO_APPEND\fP Die Datei wird im Anhängemodus geöffnet. Vor jedem \fBwrite\fP(2) wird der Dateiversatz an das Ende der Datei positioniert, wie mit \fBlseek\fP(2). Die Veränderung des Dateiversatzes und die Schreibaktion werden als einzelner, atomarer Schritt durchgeführt. .IP .\" For more background, see .\" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453946 .\" http://nfs.sourceforge.net/ \fBO_APPEND\fP 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. .TP \fBO_ASYNC\fP Aktiviert signalgetriebene E/A: erzeugt ein Signal (standardmäßig \fBSIGIO\fP, dies kann aber mit \fBfcntl\fP(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 \fBfcntl\fP(2) für weitere Details. Siehe auch FEHLER unten. .TP \fBO_CLOEXEC\fP (seit Linux 2.6.23) .\" NOTE! several other man pages refer to this text .\" FIXME . for later review when Issue 8 is one day released... .\" POSIX proposes to fix many APIs that provide hidden FDs .\" http://austingroupbugs.net/tag_view_page.php?tag_id=8 .\" http://austingroupbugs.net/view.php?id=368 Aktiviert den Schalter »close\-on\-exec« für den neuen Dateideskriptor. Durch Angabe dieses Schalters wird einem Programm ermöglicht, zusätzliche \fBfcntl\fP(2)\-\fBF_SETFD\fP\-Aktionen, um den Schalter \fBFD_CLOEXEC\fP zu setzen, zu vermeiden. .IP .\" This flag fixes only one form of the race condition; .\" The race can also occur with, for example, file descriptors .\" returned by accept(), pipe(), etc. Beachten Sie, dass die Verwendung dieses Schalters in einigen Multithread\-Programmen notwendig ist, da die Verwendung einer separaten \fBfcntl\fP(2)\-\fBF_SETFD\fP\-Aktion, um den Schalter \fBFD_CLOEXEC\fP 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 \fBfcntl\fP(2) zur gleichen Zeit zu setzen, zu der ein anderer Thread einen \fBfork\fP(2) kombiniert mit eine \fBexecve\fP(2) durchführt. Abhängig von der Reihenfolge der Ausführung kann der Ressourcenwettlauf dazu führen, dass der von \fBopen\fP(2) zurückgelieferte Dateideskriptor ungeplant von dem Programm durchgesickert ist, das von dem Kindprozess mittels \fBfork\fP(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 \fBO_CLOEXEC\fP bereit, um mit diesem Problem umzugehen. .TP \fBO_CREAT\fP Falls \fIPfadname\fP nicht existiert, wird eine normale Datei erstellt. .IP Der Eigentümer (Benutzerkennung) der neuen Datei wird auf die effektive Benutzerkennung des Prozesses gesetzt. .IP .\" As at Linux 2.6.25, bsdgroups is supported by ext2, ext3, ext4, and .\" XFS (since Linux 2.6.14). 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 \fBmount\fP(8) beschriebenen Einhängeoptionen \fIbsdgroups\fP und \fIsysvgroups\fP ab. .IP Das Argument \fIModus\fP gibt die Dateimodusbits, die beim Erstellen einer neuen Dateien angewandt werden sollen, an. Falls weder \fBO_CREAT\fP noch \fBO_TMPFILE\fP angegeben ist, wird \fIModus\fP ignoriert (und kann daher als 0 angegeben oder einfach weggelassen werden). Das Argument \fIModus\fP \fBmuss\fP angegeben werden, falls \fBO_CREAT\fP oder \fBO_TMPFILE\fP in \fISchalter\fP angegeben ist; wird es nicht angegeben, werden einige willkürliche Bytes aus dem Stack als Dateimodus gesetzt. .IP Der effektive Modus wird durch die \fIumask\fP des Prozesses wie üblich verändert: in der Abwesenheit einer Standard\-ACL ist der Modus der erstellten Datei \fI(mode\ &\ \[ti]umask)\fP. .IP Beachten Sie, dass dieser Modus nur bei zukünftigen Zugriffen auf die neu erstellte Datei gilt; der Aufruf \fBopen\fP(), der eine nur\-lesbare Datei erstellte, kann sehr wohl einen les\- und schreibbaren Dateideskriptor zurückliefern. .IP Für \fIModus\fP werden die folgenden symbolischen Konstanten bereitgestellt: .RS .TP 9 \fBS_IRWXU\fP 00700 Benutzer (Dateieigentümer) hat Lese\-, Schreibe\- und Ausführrechte .TP \fBS_IRUSR\fP 00400 Benutzer hat Leserechte .TP \fBS_IWUSR\fP 00200 Benutzer hat Schreibrechte .TP \fBS_IXUSR\fP 00100 Benutzer hat Ausführrechte .TP \fBS_IRWXG\fP 00070 Gruppe hat Lese\-, Schreib\- und Ausführrechte .TP \fBS_IRGRP\fP 00040 Gruppe hat Leserechte .TP \fBS_IWGRP\fP 00020 Gruppe hat Schreibrechte .TP \fBS_IXGRP\fP 00010 Gruppe hat Ausführrechte .TP \fBS_IRWXO\fP 00070 andere haben Lese\-, Schreib\- und Ausführrechte .TP \fBS_IROTH\fP 00004 andere haben Leserechte .TP \fBS_IWOTH\fP 00002 andere haben Schreibrechte .TP \fBS_IXOTH\fP 00001 andere haben Ausführrechte .RE .IP Laut POSIX ist der Effekt, wenn andere Bits in \fIModus\fP gesetzt werden, nicht spezifiziert. Unter Linux werden auch die folgenden Bits in \fIModus\fP berücksichtigt: .RS .TP 9 \fBS_ISUID\fP 0004000 set\-user\-ID\-Bit .TP \fBS_ISGID\fP 0002000 set\-group\-ID\-Bit (siehe \fBinode\fP(7)) .TP \fBS_ISVTX\fP 0001000 Sticky\-Bit (siehe \fBinode\fP(7)) .RE .TP \fBO_DIRECT\fP (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 \fBO_DIRECT\fP versucht, Daten synchron zu übertragen, gibt aber nicht die Garantien des Schalters \fBO_SYNC\fP, dass Daten und notwendige Metadaten übetragen wurden. Um synchrone E/A zu garantieren, muss \fBO_SYNC\fP zusätzlich zu \fBO_DIRECT\fP verwandt werden. Siehe ANMERKUNGEN für weitere Betrachtungen. .IP Eine semantisch ähnliche (aber missbilligte) Schnittstelle für Blockgeräte wird in \fBraw\fP(8) beschrieben. .TP \fBO_DIRECTORY\fP .\" But see the following and its replies: .\" http://marc.theaimsgroup.com/?t=112748702800001&r=1&w=2 .\" [PATCH] open: O_DIRECTORY and O_CREAT together should fail .\" O_DIRECTORY | O_CREAT causes O_DIRECTORY to be ignored. Falls \fIPfadname\fP kein Verzeichnis ist, schlägt damit open fehl. Dieser Schalter wurde in Linux\-Version 2.1.126 hinzugefügt, um Diensteverweigerungsangriffe zu vermeiden, falls \fBopendir\fP(3) mit einem FIFO oder Bandgerät aufgerufen wird. .TP \fBO_DSYNC\fP Schreibaktionen auf der Datei werden entsprechend den Anforderungen der synchronisierten E/A\-\fIDaten\fP\-Integritätsvervollständigung vervollständigt. .IP Zum Zeitpunkt der Rückkehr von \fBwrite\fP(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 \fBwrite\fP(2) ein Aufruf von \fBfdatasync\fP(2) gefolgt wäre). \fISiehe Hinweise unten\fP. .TP \fBO_EXCL\fP stellt sicher, dass dieser Aufruf die Datei erstellt. Falls dieser Schalter zusammen mit \fBO_CREAT\fP angegeben wird und \fIPfadname\fP bereits existiert, dann schlägt \fBopen\fP() mit dem Fehler \fBEEXIST\fP fehl. .IP .\" POSIX.1-2001 explicitly requires this behavior. Wenn diese zwei Schalter angegeben werden, wird symbolischen Links nicht gefolgt. Falls \fIPfadname\fP ein symbolischer Link ist, dann schlägt \fBopen\fP() fehl, unabhängig davon, wohin der symbolische Link verweist. .IP Im Allgemeinen ist das Verhalten von \fBO_EXCL\fP undefiniert, falls es ohne \fBO_CREAT\fP verwandt wird. Es gibt eine Ausnahme: Unter Linux 2.6 und neuer kann \fBO_EXCL\fP ohne \fBO_CREAT\fP verwandt werden, falls sich \fIPfadname\fP auf ein Blockgerät bezieht. Falls das Blockgerät vom System verwandt (d.h. eingehängt) ist, schlägt \fBopen\fP() mit dem Fehler \fBEBUSY\fP fehl. .IP Unter NFS wird \fBO_EXCL\fP 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 \fBO_EXCL\fP 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 \fBO_EXCL\fP duch NFS vermeiden müssen, können eine eindeutige Datei auf dem gleichen Dateisystem erstellen (d.h. den Rechnernamen und die PID einbauen) und \fBlink\fP(2) verwenden, um einen Link auf die Sperrdatei zu erstellen. Falls \fBlink\fP(2) den Wert 0 zurückliefert, war die Sperrung erfolgreich. Andernfalls verwenden Sie \fBstat\fP(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. .TP \fBO_LARGEFILE\fP (LFS) Erlaubt Dateien, deren Größe nicht in einem \fIoff_t\fP (aber in einem \fIoff64_t\fP) dargestellt werden kann, geöffnet zu werden. Das Makro \fB_LARGEFILE64_SOURCE\fP muss (vor dem Einbinden \fIaller\fP Header\-Dateien) definiert sein, um diese Definition zu erhalten. Das Setzen des Feature\-Test\-Makros \fB_FILE_OFFSET_BITS\fP auf 64 (statt der Verwendung von \fBO_LARGEFILE\fP) ist die bevorzugte Methode zum Zugriff auf große Dateien auf 32\-Bit\-Systemen (siehe \fBfeature_test_macros\fP(7)). .TP \fBO_NOATIME\fP (seit Linux 2.6.8) Aktualisiert die letzte Zugriffszeit der Datei (\fIst_atime\fP in dem Inode) nicht, wenn ein \fBread\fP(2) auf der Datei erfolgt. .IP Dieser Schalter kann nur verwandt werden, falls eine der folgenden Bedingungen zutrifft: .RS .IP \[bu] 3 .\" Strictly speaking: the filesystem UID Die effektive UID des Prozesses passt auf die Eigentümer\-UID des Datei. .IP \[bu] Der aufrufende Prozess verfügt über die Capability \fBCAP_FOWNER\fP in seinem Benutzernamensraum und es gibt eine Abbildung der Benutzer\-UID der Datei in den Namensraum. .RE .IP .\" The O_NOATIME flag also affects the treatment of st_atime .\" by mmap() and readdir(2), MTK, Dec 04. 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. .TP \fBO_NOCTTY\fP Falls sich \fIPfadname\fP auf ein Terminalgerät – siehe \fBtty\fP(4) – bezieht, wird es nicht das steuernde Terminal des Prozesses werden, selbst falls der Prozess noch keines hat. .TP \fBO_NOFOLLOW\fP Falls die abschließende Komponenten (d.h. der Basisname) von \fIPfadname\fP ein symbolischer Link ist, schlägt das Öffnen mit dem Fehler \fBELOOP\fP fehl. Symbolische Links in früheren Komponenten des Pfadnamens werden weiterhin aufgelöst. (Beachten Sie, dass der in diesem Fall möglich Fehler \fBELOOP\fP 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.) .IP 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. .IP .\" The headers from glibc 2.0.100 and later include a .\" definition of this flag; \fIkernels before Linux 2.1.126 will ignore it if .\" used\fP. Siehe auch \fBO_PATH\fP weiter unten. .TP \fBO_NONBLOCK\fP oder \fBO_NDELAY\fP Falls möglich, wird die Datei im nichtblockierenden Modus geöffnet. Weder das \fBopen\fP() noch folgende E/A\-Aktionen auf dem zurückgegebenen Dateideskriptor werden dazu führen, dass der aufrufende Prozess warten muss. .IP Beachten Sie, dass das Setzen dieses Schalters keine Wirkung auf die Aktion von \fBpoll\fP(2), \fBselect\fP(2), \fBepoll\fP(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 \fBO_NONBLOCK\fP\-Schalter \fIclear\fP nicht blockieren würde. .IP 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 \fBO_NONBLOCK\fP gesetzt ist. Da die Semantik von \fBO_NONBLOCK\fP 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. .IP Für die Handhabung von FIFOs (benannten Pipes), siehe auch \fBfifo\fP(7). Für eine Diskussion des Effekts von \fBO_NONBLOCK\fP im Zusammenhang mit verpflichtenden Sperren und mit Datei\-Ausleihen, siehe \fBfcntl\fP(2). .TP \fBO_PATH\fP (seit Linux 2.6.39) .\" commit 1abf0c718f15a56a0a435588d1b104c7a37dc9bd .\" commit 326be7b484843988afe57566b627fb7a70beac56 .\" commit 65cfc6722361570bfe255698d9cd4dccaf47570d .\" .\" http://thread.gmane.org/gmane.linux.man/2790/focus=3496 .\" Subject: Re: [PATCH] open(2): document O_PATH .\" Newsgroups: gmane.linux.man, gmane.linux.kernel .\" 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. \fBread\fP(2), \fBwrite\fP(2), \fBfchmod\fP(2), \fBfchown\fP(2), \fBfgetxattr\fP(2), \fBioctl\fP(2), \fBmmap\fP(2)) schlagen mit dem Fehler \fBEBADF\fP fehl. .IP Die folgenden Aktionen \fIkönnen\fP mit dem entstandenen Dateideskriptor durchgeführt werden: .RS .IP \[bu] 3 \fBclose\fP(2). .IP \[bu] .\" commit 332a2e1244bd08b9e3ecd378028513396a004a24 \fBfchdir\fP(2), falls der Dateideskriptor auf ein Verzeichnis verweist (seit Linux 3.5). .IP \[bu] \fBfstat\fP(2) (seit Linux 3.6). .IP \[bu] .\" fstat(): commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 .\" fstatfs(): commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf \fBfstatfs\fP(2) (seit Linux 3.12). .IP \[bu] Duplizieren des Dateideskriptors (\fBdup\fP(2), \fBfcntl\fP(2) \fBF_DUPFD\fP, usw.). .IP \[bu] Ermitteln und Setzen von Dateideskriptorenschaltern (\fBfcntl\fP(2) \fBF_GETFD\fP und \fBF_SETFD\fP). .IP \[bu] Ermitteln von offenen Dateistatusschaltern mittels der Aktion \fBF_GETFL\fP von \fBfcntl\fP(2): Die zurückgelieferten Schalter werden das Bit \fBO_PATH\fP enthalten. .IP \[bu] Übergabe des Dateideskriptors als Argument \fIVerzdd\fP von \fBopenat\fP() und den anderen »*at()«\-Systemaufrufen. Dazu gehört \fBlinkat\fP(2) mit \fBAT_EMPTY_PATH\fP (oder mittels \fBAT_SYMLINK_FOLLOW\fP von Procfs), selbst falls die Datei kein Verzeichnis ist. .IP \[bu] Übergabe des Dateideskriptors an einen anderen Prozess mittels UNIX\-Domain\-Sockets (siehe \fBSCM_RIGHTS\fP in \fBunix\fP(7)). .RE .IP Wenn \fBO_PATH\fP in \fISchalter\fP angegeben ist, werden die von \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP und \fBO_NOFOLLOW\fP verschiedenen Schalter\-Bits ignoriert. .IP Öffnen einer Datei oder eines Verzeichnisses mit dem Schalter \fBO_PATH\fP 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 \fBfchdir\fP(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 \fBO_RDONLY\fP, dass der Aufrufende Leseberechtigungen am Objekt hat, selbst wenn nachfolgende Aktionen (z.B. \fBfchdir\fP(2), \fBfstat\fP(2)) keine Leseberechtigungen am Objekt benötigen. .IP Falls \fIPfadname\fP ein symbolischer Link ist und auch der Schalter \fBO_NOFOLLOW\fP angegeben ist, dann liefert der Aufruf einen Dateideskriptor zurück, der sich auf den symbolischen Link bezieht. Dieser Dateideskriptor kann als Argument \fIVerzdd\fP in Aufrufen von \fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2) und \fBreadlinkat\fP(2) mit einem leeren Dateinamen verwandt werden, um Aufrufe auf den symbolischen Link anzuwenden. .IP Falls sich \fIPfadname\fP 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. \fBfstatfs\fP(2) kann dann dazu verwandt werden, zu bestimmen, ob es sich tatsächlich um ein unausgelösten Selbsteinhängepunkt handelt (\fB.f_type == AUTOFS_SUPER_MAGIC\fP). .IP Eine Einsatz von \fBO_PATH\fP für reguläre Dateien ist die Bereitstellung des Äquivalents der Funktionalität \fBO_EXEC\fP 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: .IP .in +4n .EX 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); .EE .in .IP Ein \fBO_PATH\fP\-Dateideskriptor kann auch an das Argument von \fBfexecve\fP(3) weitergegeben werden. .TP \fBO_SYNC\fP Schreibaktionen auf dieser Datei werden entsprechend den Anforderungen der synchronisierten E/A\-\fIDatei\fP\-Integritätsvervollständigung vervollständigt (in Kontrast zu der durch \fBO_DSYNC\fP bereitgestellten synchronisierten E/A\-\fIDatei\fP\-Integritätsvervollständigung). .IP Zum Zeitpunkt, zu dem \fBwrite\fP(2) (und ähnliche) zurückkehrt, wurden die Ausgabedaten und zugehörigen Dateimetadaten bereits an die darunterliegende Hardware übergeben (d.h. als ob jeder \fBwrite\fP(2) von einem Aufruf von \fBfsync\fP(2) gefolgt worden wäre.) \fISiehe ANMERKUNGEN unten\fP. .TP \fBO_TMPFILE\fP (seit Linux 3.11) .\" commit 60545d0d4610b02e55f65d141c95b18ccf855b6e .\" commit f4e0c30c191f87851c4a53454abb55ee276f4a7e .\" commit bb458c644a59dbba3a1fe59b27106c5e68e1c4bd Erstellt eine unbenannte temporäre normale Datei. Das Argument \fIPfadname\fP 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. .IP \fBO_TMPFILE\fP muss als eines aus \fBO_RDWR\fP oder \fBO_WRONLY\fP und optional \fBO_EXCL\fP festgelegt werden. Falls \fBO_EXCL\fP nicht festgelegt wird, dann kann \fBlinkat\fP(2) dazu verwandt werden, die temporäre Datei in das Dateisystem zu linken, womit diese permanent wird, unter Verwendung von Code wie dem folgenden: .IP .in +4n .EX char path[PATH_MAX]; fd = open("/Pfad/zum/Verzeichnis", 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 (die zur Verwendung von AT_EMPTY_PATH mit linkat(2)) erforderlich ist) und ein proc(5)\-Dateisystem eingehängt ist, kann der obige Aufruf von linkat(2) wie folgt ersetzt werden: \& snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd); linkat(AT_FDCWD, path, AT_FDCWD, "/Pfad/zur/Datei", AT_SYMLINK_FOLLOW); */ .EE .in .IP In diesem Fall bestimmt das Argument \fIModus\fP von \fBopen\fP() den Dateirechtemodus, wie bei \fBO_CREAT\fP. .IP Wird \fBO_EXCL\fP in Zusammenhang mit \fBO_TMPFILE\fP festgelegt, dann wird verhindert, dass die Datei in das Dateisystem in der oben beschriebenen Weise gelinkt wird. (Beachten Sie, dass die Bedeutung von \fBO_EXCL\fP in diesem Fall anders als sonst ist.) .IP .\" Inspired by http://lwn.net/Articles/559147/ Es gibt zwei Haupteinsatzgebiete für \fBO_TMPFILE\fP: .RS .IP \[bu] 3 Verbesserte Funktionalität von \fBtmpfile\fP(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. .IP \[bu] Erstellen einer Datei, die ursprünglich unsichtbar ist, die dann mit den Daten gefüllt und angepasst wird, um die korrekten Dateisystemattribute zu erhalten ((\fBfchown\fP(2), \fBfchmod\fP(2), \fBfsetxattr\fP(2) usw.), bevor sie atomar in das Dateisystem in einer vollständigen Form gelinkt wird (mittels \fBlinkat\fP(2) wie oben beschrieben). .RE .IP .\" To check for support, grep for "tmpfile" in kernel sources .\" commit 99b6436bc29e4f10e4388c27a3e4810191cc4788 .\" commit ab29743117f9f4c22ac44c13c1647fb24fb2bafe .\" commit ef3b9af50bfa6a1f02cd7b3f5124b712b1ba3e3c .\" commit 50732df02eefb39ab414ef655979c2c9b64ad21c \fBO_TMPFILE\fP 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). .TP \fBO_TRUNC\fP Falls die Datei bereits existiert, eine reguläre Datei ist und der Zugriffsmodus Schreiben erlaubt (d.h. \fBO_RDWR\fP oder \fBO_WRONLY\fP ist), dann wird sie auf die Länge 0 abgeschnitten. Falls die Datei ein FIFO oder Terminalgerät ist, dann wird der Schalter \fBO_TRUNC\fP ignoriert. Andernfalls ist die Auswirkung von \fBO_TRUNC\fP nicht festgelegt. .SS creat() Ein Aufruf von \fBcreat\fP() is äquivalent zum Aufruf von \fBopen\fP() mit \fISchalter\fP identisch zu \fBO_CREAT|O_WRONLY|O_TRUNC\fP. .SS openat() Der Systemaufruf \fBopenat\fP() arbeitet genau wie \fBopen\fP(), außer den hier beschriebenen Unterschieden. .P Das \fIVerzdd\fP\-Argument wird in Verbindung mit dem \fIPfadname\fP\-Argument wie folgt verwendet: .IP \[bu] 3 Falls der in \fIPfadname\fP übergebene Pfadname absolut ist, wird \fIVerzdd\fP ignoriert. .IP \[bu] Falls der angegebene \fIPfadname\fP relativ ist und \fIVerzdd\fP den speziellen Wert \fBAT_FDCWD\fP enthält, dann wird \fIPfadname\fP relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie \fBopen\fP()). .IP \[bu] Falls der in \fIPfadname\fP angegebene Pfadname relativ ist, dann wird er relativ zu dem Verzeichnis interpretiert, auf das der Dateideskriptor \fIVerzdd\fP verweist (statt relativ zu dem aktuellen Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei \fBopen\fP() für einen relativen Pfadnamen erfolgt). In diesem Fall muss \fIVerzdd\fP ein Verzeichnis sein, das zum Lesen geöffnet wurde, oder den Schalter \fBO_PATH\fP vewenden. .P .\" Falls der angegebene \fIPfadname\fP relativ und \fIVerzdd\fP kein gültiger Dateideskriptor ist, wird ein Fehler (\fBEBADF\fP) ausgegeben. (Die Angabe einer ungültigen Dateideskriptornummer in \fIVerzdd\fP kann dazu verwendet werden, um sicherzustellen, dass der \fIPfadname\fP absolut ist.) .SS openat2(2) Der Systemaufruf \fBopenat2\fP(2) ist eine Erweiterung von \fBopenat\fP() und stellt eine Obermenge der Funtionalitäten von \fBopenat\fP() zur Verfügung. Er ist separat in \fBopenat2\fP(2) dokumentiert. .SH RÜCKGABEWERT \fBopen\fP(), \fBopenat\fP() und \fBcreat\fP() liefern bei Erfolg den neuen Dateideskriptor zurück (eine nicht negative Ganzzahl) oder \-1, falls ein Fehler auftrat (in diesem Fall wird \fIerrno\fP gesetzt, um den Fehler anzuzeigen). .SH FEHLER \fBopen\fP(), \fBopenat\fP() und \fBcreat\fP() können mit den folgenden Fehlern fehlschlagen: .TP \fBEACCES\fP Der angeforderte Zugriff auf die Datei ist nicht erlaubt oder die Suchberechtigung ist für eines der Verzeichnisse im Pfadanteil von \fIPfadname\fP verweigert oder die Datei existierte noch nicht oder Schreibzugriff auf das Elternverzeichnis ist nicht erlaubt. (Siehe auch \fBpath_resolution\fP(7).) .TP \fBEACCES\fP .\" commit 30aba6656f61ed44cba445a3c0d38b296fa9e8f5 Ist \fBO_CREAT\fP angegeben, dann ist der \fIprotected_fifos\fP\- oder \fIprotected_regular\fP\-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 \fI/proc/sys/fs/protected_fifos\fP und \fI/proc/sys/fs/protected_regular\fP in \fBproc_sys_fs\fP(5). .TP \fBEBADF\fP (\fBopenat\fP()) Der \fIPfadname\fP ist relativ, aber \fIVerzdd\fP ist weder \fBAT_FDCWD\fP noch ein gültiger Dateideskriptor. .TP \fBEBUSY\fP \fBO_EXCL\fP wurde in \fISchalter\fP angegeben und \fIPfadname\fP bezieht sich auf ein blockorientiertes Gerät, das vom System verwendet wird (zum Beispiel, wenn es eingehängt ist). .TP \fBEDQUOT\fP Wo \fBO_CREAT\fP angegeben ist existiert die Datei nicht und das Kontingent des Benutzers an Plattenblöcken oder Inodes auf dem Dateisystem ist erschöpft. .TP \fBEEXIST\fP \fIPfadname\fP existiert bereits und \fBO_CREAT\fP und \fBO_EXCL\fP wurden verwandt. .TP \fBEFAULT\fP \fIPfadname\fP zeigt aus dem für Sie zugänglichen Adressraum heraus. .TP \fBEFBIG\fP siehe \fBEOVERFLOW\fP .TP \fBEINTR\fP Während der Aufruf wartet, bis ein langsames Gerät vollständig geöffnet ist (z.B. ein FIFO, siehe \fBfifo\fP(7)), wurde er von einem Signal\-Handler unterbrochen, siehe \fBsignal\fP(7). .TP \fBEINVAL\fP Das Dateisystem unterstützt den Schalter \fBO_DIRECT\fP nicht. Lesen Sie \fBANMERKUNGEN\fP für weitere Informationen. .TP \fBEINVAL\fP .\" In particular, __O_TMPFILE instead of O_TMPFILE Unzulässiger Wert in \fIflags\fP. .TP \fBEINVAL\fP \fBO_TMPFILE\fP wurde in \fISchalter\fP angegeben, aber weder \fBO_WRONLY\fP noch \fBO_RDWR\fP wurden angegeben. .TP \fBEINVAL\fP \fBO_CREAT\fP wurde in \fISchalter\fP angegeben und die abschließende Komponente (»basename«) des \fIPfadname\fP der neuen Datei ist ungültig (d.h. sie enthält im unterliegenden Dateisystem nicht erlaubte Zeichen). .TP \fBEINVAL\fP Die abschließende Komponente (»basename«) des \fIPfadnames\fP ist ungültig (d.h. sie enthält im unterliegenden Dateisystem nicht erlaubte Zeichen). .TP \fBEISDIR\fP \fIPfadname\fP bezieht sich auf ein Verzeichnis und der Zugriff beinhaltete Schreiben (d.h. \fBO_WRONLY\fP oder \fBO_RDWR\fP ist gesetzt). .TP \fBEISDIR\fP \fIPfadname\fP bezieht sich auf ein existierendes Verzeichnis, \fBO_TMPFILE\fP und entweder \fBO_WRONLY\fP oder \fBO_RDWR\fP wurde in \fISchalter\fP angegeben, aber diese Kernelversion stellt die Funktionalität \fBO_TMPFILE\fP nicht zur Verfügung. .TP \fBELOOP\fP Bei der Auflösung von \fIPfadname\fP wurden zu viele symbolische Links gefunden. .TP \fBELOOP\fP \fIPfadname\fP war ein symbolischer Link und \fISchalter\fP legte \fBO_NOFOLLOW\fP aber nicht \fBO_PATH\fP fest. .TP \fBEMFILE\fP Die pro\-Prozess\-Begrenzung der Anzahl offener Dateideskriptoren wurde erreicht (siehe die Beschreibung von \fBRLIMIT_NOFILE\fP in \fBgetrlimit\fP(2)). .TP \fBENAMETOOLONG\fP \fIPfadname\fP war zu lang. .TP \fBENFILE\fP Die systemweite Beschränkung für die Gesamtzahl offener Dateien wurde erreicht. .TP \fBENODEV\fP \fIPfadname\fP bezieht sich auf eine Geräte\-Spezialdatei und kein entsprechendes Gerät existiert. (Dies ist ein Fehler im Linux\-Kernel; in dieser Situation muss \fBENXIO\fP zurückgeliefert werden.) .TP \fBENOENT\fP \fBO_CREAT\fP ist nicht gesetzt und die angegebene Datei existiert nicht. .TP \fBENOENT\fP Eine Verzeichniskomponente von \fIPfadname\fP existiert nicht oder ist ein toter symbolischer Link. .TP \fBENOENT\fP \fIPfadname\fP bezieht sich auf ein nicht existierendes Verzeichnis, \fBO_TMPFILE\fP und entweder \fBO_WRONLY\fP oder \fBO_RDWR\fP wurde in \fISchalter\fP angegeben, aber diese Kernelversion stellt die Funktionalität \fBO_TMPFILE\fP nicht zur Verfügung. .TP \fBENOMEM\fP 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 \fBpipe\fP(7). .TP \fBENOMEM\fP Es war nicht genügend Kernelspeicher verfügbar. .TP \fBENOSPC\fP \fIPfadname\fP sollte erstellt werden, aber das Gerät, das \fIPfadname\fP enthält, hat für die neue Datei keinen Platz. .TP \fBENOTDIR\fP Eine als Verzeichnis verwandte Komponente in \fIPfadname\fP ist tatsächlich kein Verzeichnis oder \fBO_DIRECTORY\fP wurde angegeben, aber \fIPfadname\fP war kein Verzeichnis. .TP \fBENOTDIR\fP (\fBopenat\fP()) \fIPfadname\fP ist ein relativer Pfadname und \fIVerzdd\fP ist ein Dateideskriptor, der sich auf eine Datei statt auf ein Verzeichnis bezieht. .TP \fBENXIO\fP \fBO_NONBLOCK\fP | \fBO_WRONLY\fP ist gesetzt, die benannte Datei ist ein FIFO und kein Prozess hat den FIFO zum Lesen offen. .TP \fBENXIO\fP Die Datei ist eine Geräte\-Spezialdatei und kein entsprechendes Gerät existiert. .TP \fBENXIO\fP Die Datei ist ein UNIX Domain Socket. .TP \fBEOPNOTSUPP\fP Das Dateisystem, das \fIPfadname\fP enthält, unterstützt \fBO_TMPFILE\fP nicht. .TP \fBEOVERFLOW\fP .\" See http://bugzilla.kernel.org/show_bug.cgi?id=7253 .\" "Open of a large file on 32-bit fails with EFBIG, should be EOVERFLOW" .\" Reported 2006-10-03 \fIPfadname\fP bezieht sich auf eine normale Datei, die zu groß zum Öffnen ist. Das normale Szenario ist, dass eine auf einer 32\-Bit\-Plattform ohne \fI\-D_FILE_OFFSET_BITS=64\fP übersetzte Anwendung versuchte, eine Datei zu öffnen, deren Größe \fI(1<<31)\-1\fP byte überschritt; siehe auch \fBO_LARGEFILE\fP weiter oben. Dies ist der durch POSIX.1 festgelegte Fehler; in Versionen vor 2.6.24 gab Linux in diesem Fall den Fehler \fBEFBIG\fP zurück. .TP \fBEPERM\fP .\" Strictly speaking, it's the filesystem UID... (MTK) Der Schalter \fBO_NOATIME\fP war angegeben, aber die effektive Benutzerkennung des Aufrufenden passte nicht auf den Eigentümer der Datei und der Aufrufende war nicht privilegiert. .TP \fBEPERM\fP Die Aktion wurde durch eine Dateiversiegelung verhindert; siehe \fBfcntl\fP(2). .TP \fBEROFS\fP \fIPfadname\fP bezieht sich auf eine Datei auf einem schreibgeschützten Dateisystem, und Schreibzugriff wurde angefordert. .TP \fBETXTBSY\fP \fIPfadname\fP bezieht sich auf ein ausführbares Abbild, das derzeit ausgeführt wird und Schreibzugriff wurde erbeten. .TP \fBETXTBSY\fP \fIPfadname\fP bezieht sich auf eine Datei, die derzeit als Auslagerungsdatei verwandt wird und \fBO_TRUNC\fP wurde festgelegt. .TP \fBETXTBSY\fP \fIPfadname\fP bezieht sich auf eine Datei, die derzeit vom Kernel gelesen wird (z.B. für das Laden von Modulen/Firmware) und Schreibzugriff wurde erbeten. .TP \fBEWOULDBLOCK\fP Der Schalter \fBO_NONBLOCK\fP wurde angegeben und eine inkompatible Ausleihe wurde auf der Datei gehalten (siehe \fBfcntl\fP(2)). .SH VERSIONEN .\" Linux 2.0, 2.5: truncate .\" Solaris 5.7, 5.8: truncate .\" Irix 6.5: truncate .\" Tru64 5.1B: truncate .\" HP-UX 11.22: truncate .\" FreeBSD 4.7: truncate Der (undefinierte) Effekt von \fBO_RDONLY | O_TRUNC\fP unterscheidet sich in vielen Implementierungen. Auf vielen Systemen wird die Datei tatsächlich abgeschnitten. .SS "Synchronisierte E/A" Die Option »synchronisierte E/A« von POSIX.1\-2008 spezifiziert verschiedene Varianten der synchronisierten E/A und spezifiziert Schalter \fBO_SYNC\fP, \fBO_DSYNC\fP und \fBO_RSYNC\fP von \fBopen\fP() für die Steuerung des Verhaltens. Unabhängig davon, ob eine Implementierung diese Option unterstützt muss sie mindestens die Verwendung von \fBO_SYNC\fP für reguläre Dateien unterstützen. .P Linux implementiert \fBO_SYNC\fP und \fBO_DSYNC\fP, aber nicht \fBO_RSYNC\fP. Etwas inkorrekt definiert Glibc \fBO_RSYNC\fP auf den gleichen Wert wie \fBO_SYNC\fP. (\fBO_RSYNC\fP wird auf HP PA\-RISC in der Linux\-Header\-Datei \fI\fP definiert, aber nicht benutzt.) .P \fBO_SYNC\fP stellt synchronisierte E/A\-\fIDatei\fP\-Integritätsvervollständigung bereit. Das bedeutet, Schreibaktionen schieben ihre Daten und zugehörigen Metadaten an die darunterliegende Hardware. \fBO_DSYNC\fP stellt synchronisierte E/A\-\fIDaten\fP\-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. .P Um den Unterschied zwischen den zwei Arten von Vervollständigung zu verstehen, betrachen Sie zwei verschiedene Dateimetadaten: den Zeitstempel der letzten Änderung (\fIst_mtime\fP) 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 \fBO_DSYNC\fP nur garantieren, dass Aktualisierungen der Dateilängen\-Metadaten rausgeschoben werden (während \fBO_SYNC\fP immer auch das Metadatum des Zeitstempels der letzten Änderung rausschieben würde). .P Vor Linux 2.6.33 implementierte Linux nur den Schalter \fBO_SYNC\fP für \fBopen\fP(). Als dieser Schalter spezifiziert wurde, stellten die meisten Dateisysteme das Äquivalent von synchronisierter E/A\-\fIDaten\fP\-Integritätsvervollständigung bereit (d.h. \fBO_SYNC\fP war tatsächlich als Äquivalent von \fBO_DSYNC\fP implementiert). .P .\" Seit Linux 2.6.33 wird korrekte Unterstützung für \fBO_SYNC\fP bereitgestellt. Um Rückwärtskompatibilität sicherzustellen wurde aber \fBO_DSYNC\fP mit dem gleichen Wert wie das historische \fBO_SYNC\fP definiert und \fBO_SYNC\fP wurde als neuer (Zweibit\-)Schalterwert definiert, der den Wert des Schalters \fBO_DSYNC\fP enthält. Das stellt sicher, dass Anwendungen, die gegen neue Header übersetzt wurden, mindestens die Semantik von \fBO_DSYNC\fP auf Linux vor 2.6.33 erhalten. .SS "Unterschiede C\-Bibliothek/Kernel" .\" Seit Version 2.26 setzt die Glibc\-Wrapper\-Funktion für \fBopen\fP() den Systemaufruf \fBopenat\fP() statt des Systemaufrufs \fBopen\fP() des Kernels ein. Für bestimmte Architekturen stimmt dies auch für Glibc\-Versionen vor 2.26. .SH STANDARDS .TP \fBopen\fP() .TQ \fBcreat\fP() .TQ \fBopenat\fP() POSIX.1\-2008. .P \fBopenat2\fP(2) Linux. .P Die Schalter \fBO_DIRECT\fP, \fBO_NOATIME\fP, \fBO_PATH\fP und \fBO_TMPFILE\fP sind Linux\-spezifisch. Sie müssen \fB_GNU_SOURCE\fP definieren, um ihre Definitionen zu erhalten. .P Die Schalter \fBO_CLOEXEC\fP, \fBO_DIRECTORY\fP und \fBO_NOFOLLOW\fP sind nicht in POSIX.1\-2001 sondern in POSIX.1\-2008 spezifiziert. Seit Glibc 2.12 kann ihre Definition erhalten werden, indem entweder \fB_POSIX_C_SOURCE\fP mit einem Wert größer als oder identisch zu 200809L definiert wird oder durch \fB_XOPEN_SOURCE\fP mit einem Wert größer als oder identisch zu 700. In Glibc 2.11 und älter kann die Definition über die Definition von \fB_GNU_SOURCE\fP erhalten werden. .SH GESCHICHTE .TP \fBopen\fP() .TQ \fBcreat\fP() SVr4, 4.3BSD, POSIX.1\-2001. .TP \fBopenat\fP() POSIX.1\-2008. Linux 2.6.16, Glibc 2.4. .SH ANMERKUNGEN Unter Linux wird der Schalter \fBO_NONBLOCK\fP 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 \fBioctl\fP(2) zu erhalten. .P Beachten Sie, dass \fBopen\fP() Spezial\-Gerätedateien öffnen kann, aber \fBcreat\fP() sie nicht erstellen kann. Verwenden Sie stattdessen \fBmknod\fP(2). .P Falls die Datei neu erstellt wurde, werden ihre Felder \fIst_atime\fP, \fIst_ctime\fP, \fIst_mtime\fP (Zeit des letzten Zugriffs, Zeit der letzten Statusänderung und Zeit der letzten Änderung, siehe \fBstat\fP(2)) auf die aktuelle Zeit gesetzt und ebenso die Felder \fIst_ctime\fP und \fIst_mtime\fP des Elternverzeichnisses. Andernfalls, falls die Datei aufgrund des Schalters \fBO_TRUNC\fP geändert wurde, werden ihre Felder \fIst_ctime\fP und \fIst_mtime\fP auf die aktuelle Zeit gesetzt. .P Die Dateien im Verzeichnis \fI/proc/\fPPID\fI/fd\fP zeigen die offenen Dateideskriptoren des Prozesses mit der PID \fIPID\fP. Die Dateien im Verzeichnis \fI/proc/\fPPID\fI/fdinfo\fP zeigen noch mehr Informationen über diese Dateideskriptoren. Siehe \fBproc\fP(5) für weitere Details über beide Verzeichnisse. .P .\" .\" Die Linux\-Header\-Datei \fB\fP definiert \fBO_ASYNC\fP nicht, es wird stattdessen das (von BSD abgeleitete) Synonym \fBFASYNC\fP definiert. .SS "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 – \fIstruct file\fP genannt. .P Wenn ein Dateideskriptor (mit \fBdup\fP(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 \fBfork\fP(2) erstellter Kindprozess erbt Duplikate der Dateideskriptoren seines Elternprozesses und diese Duplikate beziehen sich auf die gleichen offenen Dateideskriptoren. .P Jedes \fBopen\fP() einer Datei erstellt eine neue offene Dateideskription; daher kann es mehrere offene Dateideskriptionen geben, die einem Datei\-Inode entsprechen. .P .\" Unter Linux kann die Aktion \fBKCMP_FILE\fP von \fBkcmp\fP(2) zum Testen, ob sich zwei Dateideskriptoren (in dem gleichen Prozess oder in zwei verschiedenen Prozessen) auf die gleiche offene Dateideskription beziehen, verwandt werden. .SS NFS Es gibt mehrere Unglücklichkeiten im Protokoll, das NFS unterliegt, die unter anderem \fBO_SYNC\fP und \fBO_NDELAY\fP betreffen. .P .\" .\" Auf NFS\-Dateisystemen mit aktivierter UID\-Abbildung könnte \fBopen\fP() einen Dateideskriptor zurückliefern, aber \fBread\fP(2)\-Anfragen werden beispielsweise mit \fBEACCES\fP verweigert. Dies erfolgt, da der Client \fBopen\fP() durchführt, indem er die Rechte prüft, aber die UID\-Abbildung auf dem Server bei Lese\- und Schreibanfragen erfolgt. .SS FIFOs .\" .\" Öffnen des Lese\- oder Schreibendes eines FIFOS blockiert, bis das andere Ende auch geöffnet wurde (durch einen anderen Prozess oder Thread). Siehe \fBfifo\fP(7) für weitere Details. .SS Dateizugriffsmodus Anders als andere Werte, die in \fISchalter\fP angegeben werden können, legen die \fIZugriffsmodus\fP\-Werte \fBO_RDONLY\fP, \fBO_WRONLY\fP und \fBO_RDWR\fP nicht individuelle Bits fest. Stattdessen definieren sie die untersten zwei Bits von \fISchalter\fP und sind respektive als 0, 1 und 2 definiert. Mit anderen Worten, die Kombination \fBO_RDONLY | O_WRONLY\fP ist ein logischer Fehler und hat bestimmt nicht die gleiche Bedeutung wie \fBO_RDWR\fP. .P .\" See for example util-linux's disk-utils/setfdprm.c .\" For some background on access mode 3, see .\" http://thread.gmane.org/gmane.linux.kernel/653123 .\" "[RFC] correct flags to f_mode conversion in __dentry_open" .\" LKML, 12 Mar 2008 .\" .\" Linux reserviert den besonderen, nicht standardisierten Zugriffsmodus 3 (binär 11) in \fISchalter\fP 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 \fBioctl\fP(2)\-Aktionen benutzt werden kann. .SS "Begründung für openat()\- und andere Verzeichnis\-Dateideskriptor APIs" \fBopenat\fP() und andere Systemaufrufe und Bibliotheksfunktionen, die ein Verzeichnis\-Dateideskriptor als Argument akzeptieren (d.h. \fBexecveat\fP(2), \fBfaccessat\fP(2), \fBfanotify_mark\fP(2), \fBfchmodat\fP(2), \fBfchownat\fP(2), \fBfspick\fP(2), \fBfstatat\fP(2), \fBfutimesat\fP(2), \fBlinkat\fP(2), \fBmkdirat\fP(2), \fBmknodat\fP(2), \fBmount_setattr\fP(2), \fBmove_mount\fP(2), \fBname_to_handle_at\fP(2), \fBopen_tree\fP(2), \fBopenat2\fP(2), \fBreadlinkat\fP(2), \fBrenameat\fP(2), \fBrenameat2\fP(2), \fBstatx\fP(2), \fBsymlinkat\fP(2), \fBunlinkat\fP(2), \fButimensat\fP(2), \fBmkfifoat\fP(3) und \fBscandirat\fP(3)) behandeln zwei Probleme mit der älteren Schnittstelle, die dieser voranging. Hier erfolgt die Erläuterung am \fBopenat\fP()\-Aufruf, aber der Grund ist analog für die anderen Schnittstellen. .P Erstens erlaubt \fBopenat\fP() es Anwendungen, Race\-Conditions zu vermeiden, die bei der Verwendung von \fBopen\fP() 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 \fBopen\fP() übergeben wird, parallel zum Aufruf von \fBopen\fP() geändert werden können. Nehmen Sie beispielsweise an, dass Sie die Datei \fIdir1/dir2/xxx.dep\fP öffnen möchten, falls \fIdir1/dir2/xxx\fP existiert. Das Problem besteht darin, das sich zwischen der Existenzüberprüfung und dem Schritt der Dateierstellung \fIdir1\fP oder \fIdir2\fP (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 \fIVerzdd\fP von (beispielsweise) \fBfstatat\fP(2) und \fBopenat\fP() verwandt wird. Die Verwendung des Dateideskriptors \fIVerzdd\fP hat auch weitere Vorteile: .IP \[bu] 3 Der Dateideskriptor ist eine stabile Referenz zu dem Verzeichnis, selbst falls das Verzeichnis umbenannt wird. .IP \[bu] Der offene Dateideskriptor verhindert, dass das darunterliegende Dateisystem ausgehängt wird, genauso als wenn ein Prozess sein aktuelles Arbeitsverzeichnis auf dem Dateisystem hat. .P Zweitens erlaubt \fBopenat\fP() 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 \fI/proc/self/fd/\fPVerzdd erreicht werden.) .P Das Argument \fIVerzdd\fP für diese APIs kann mittels \fBopen\fP() oder \fBopenat\fP() zum Öffnen eines Verzeichnisses erhalten werden (mit entweder dem Schalter \fBO_RDONLY\fP oder \fBO_PATH\fP). Alternativ kann ein solcher Dateideskriptor durch Anwendung von \fBdirfd\fP(3) auf einen mittels \fBopendir\fP(3) erzeugten Verzeichnisdatenstrom erhalten werden. .P .\" .\" Wird diesen APIs ein \fIVerzdd\fP\-Argument von \fBAT_FDCWD\fP ü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 \fISchalter\fP, das Zugriff auf die Funktionalität gewährt, die mit den entsprechenden konventionellen APIs nicht verfügbar ist. .SS O_DIRECT Der Schalter \fBO_DIRECT\fP 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 \fBO_DIRECT\fP\-E/A unterscheidet sich auch; er kann entweder mit \fBEINVAL\fP fehlschlagen oder auf gepufferten E/A ausweichen. .P Seit Linux 6.1 können die Unterstützung für \fBO_DIRECT\fP und Ausrichtungsbeschränkungen für eine Datei mittels \fBstatx\fP(2) unter Verwendung des Schalters \fBSTATX_DIOALIGN\fP abgefragt werden. Die Unterstützung für \fBSTATX_DIOALIGN\fP unterscheidet sich je nach Dateisystem; siehe \fBstatx\fP(2). .P Einige Dateisysteme stellen ihre eigene Schnnittstelle zur Abfrage von \fBO_DIRECT\fP\-Ausrichtungsbeschränkungen bereit. Wenn verfügbar, sollte \fBSTATX_DIOALIGN\fP stattdessen verwendet werden. .P 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 \fBioctl\fP(2) \fBBLKSSZGET\fP oder von der Shell mittels folgendem Befehl ermittelt werden: .P .in +4n .EX blockdev \-\-getss .EE .in .P \fBO_DIRECT\fP\-E/As sollten niemals gleichzeitig mit dem Systemaufruf \fBfork\fP(2) ausgeführt werden, falls der Speicherpuffer ein privates Mapping ist (das heißt, jede mit dem Schalter \fBMAP_PRIVATE\fP von \fBmmap\fP(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 \fBfork\fP(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 \fBO_DIRECT\fP\-E/As mittels \fBshmat\fP(2) oder \fBmmap\fP(2) mit dem Schalter \fBMAP_SHARED\fP erzeugt wurde. Außerdem gilt die Einschränkung nicht, wenn der Speicherpuffer mit \fBmadvise\fP(2) als \fBMADV_DONTFORK\fP deklariert wurde, was sicherstellt, dass es nach dem Aufruf von \fBfork\fP(2) für den Kindprozess nicht verfügbar ist. .P Der Schalter \fBO_DIRECT\fP wurde in SGI IRIX eingeführt, wo er Ausrichtungsbeschränkungen hat, die denen von Linux 2.4 ähnlich sind. IRIX hat außerdem einen \fBfcntl\fP(2)\-Aufruf, um geeignete Ausrichtungen und Größen abzufragen. FreeBSD 4.x führte einen gleichnamigen Schalter ein, jedoch ohne Ausrichtungsbeschränkungen. .P Die Unterstützung für \fBO_DIRECT\fP 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 \fBopen\fP() mit dem Fehler \fBEINVAL\fP fehl, falls er verwandt wird. .P Anwendungen sollten das Vermischen von \fBO_DIRECT\fP 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 \fBmmap\fP(2) von Dateien mit direktem E/A auf die gleichen Dateien vermeiden. .P Das Verhalten von \fBO_DIRECT\fP 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 \fBO_DIRECT\fP\-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 \fBO_DIRECT\fP 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 \fBO_DIRECT\fP\-E/A fest. .P In Zusammenfassung: \fBO_DIRECT\fP ist ein extrem leistungsfähiges Werkzeug, das mit Vorsicht verwandt werden sollte. Es wird empfohlen, dass Anwendungen die Verwendung von \fBO_DIRECT\fP als Leistungssteigerungsoption betrachten, die standardmäßig deaktiviert ist. .SH FEHLER .\" FIXME . Check bugzilla report on open(O_ASYNC) .\" See http://bugzilla.kernel.org/show_bug.cgi?id=5993 Derzeit ist es nicht möglich, Signal\-getriebene E/A zu aktivieren, indem \fBO_ASYNC\fP beim Aufruf von \fBopen\fP() verwandt wird; siehe \fBfcntl\fP(2), um diesen Schalter zu aktivieren. .P Es muss auf zwei verschiedene Fehler\-Codes, \fBEISDIR\fP und \fBENOENT\fP geprüft werden, wenn versucht wird, zu bestimmen, ob der Kernel die Funktionalität \fBO_TMPFILE\fP unterstützt. .P Wenn sowohl \fBO_CREAT\fP als auch \fBO_DIRECTORY\fP in \fISchalter\fP angegeben sind und die durch \fIPfadname\fP angegebene Datei nicht existiert, wird \fBopen\fP() eine normale Datei erstellen (d.h. \fBO_DIRECTORY\fP wird ignoriert). .SH "SIEHE AUCH" \fBchmod\fP(2), \fBchown\fP(2), \fBclose\fP(2), \fBdup\fP(2), \fBfcntl\fP(2), \fBlink\fP(2), \fBlseek\fP(2), \fBmknod\fP(2), \fBmmap\fP(2), \fBmount\fP(2), \fBopen_by_handle_at\fP(2), \fBopenat2\fP(2), \fBread\fP(2), \fBsocket\fP(2), \fBstat\fP(2), \fBumask\fP(2), \fBunlink\fP(2), \fBwrite\fP(2), \fBfopen\fP(3), \fBacl\fP(5), \fBfifo\fP(7), \fBinode\fP(7), \fBpath_resolution\fP(7), \fBsymlink\fP(7) .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Mario Blättermann , Chris Leick , Dr. Tobias Quathamer und Helge Kreutzmann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .