.\" -*- 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 .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" 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 "30. April 2018" Linux Linux\-Programmierhandbuch .SH BEZEICHNUNG open, openat, creat \- eine Datei öffnen und möglicherweise erzeugen .SH ÜBERSICHT .nf \fB#include \fP \fB#include \fP \fB#include \fP .PP \fBint open(const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB);\fP \fBint open(const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB, mode_t \fP\fImode\fP\fB);\fP .PP \fBint creat(const char *\fP\fIpathname\fP\fB, mode_t \fP\fImode\fP\fB);\fP .PP \fBint openat(int \fP\fIdirfd\fP\fB, const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB);\fP \fBint openat(int \fP\fIdirfd\fP\fB, const char *\fP\fIpathname\fP\fB, int \fP\fIflags\fP\fB, mode_t \fP\fImode\fP\fB);\fP .fi .PP .in -4n Mit Glibc erforderliche Makros (siehe \fBfeature_test_macros\fP(7)): .in .PP \fBopenat\fP(): .PD 0 .ad l .RS 4 .TP 4 Seit Glibc 2.10: _POSIX_C_SOURCE\ >=\ 200809L .TP Vor Glibc 2.10: _ATFILE_SOURCE .RE .ad .PD .SH BESCHREIBUNG Der Systemaufruf \fBopen\fP() öffnet eine durch \fIpathname\fP festgelegte Datei. Falls die angegebene Datei nicht existiert, kann sie optional (falls \fBO_CREAT\fP in \fIflags\fP festgelegt wurde) durch \fBopen\fP() erstellt werden. .PP Der Rückgabewert von \fBopen\fP() ist ein Dateideskriptor, eine kleine, nicht negative Ganzzahl, die in nachfolgenden Systemaufrufen (\fBread\fP(2), \fBwrite\fP(2), \fBlseek\fP(2), \fBfcntl\fP(2) usw.) genutzt wird, um den Bezug zu der offenen Datei herzustellen. Der bei einem erfolgreichen Aufruf zurückgelieferte Dateideskriptor wird der niedrigstzahlige, noch nicht für den Prozess offene Dateideskriptor sein. .PP 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)). .PP 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 \fIpathname\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. .PP Das Argument \fIflags\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. .PP .\" 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 \fIflags\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. .PP 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 Festlegung 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 \fIpathname\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 2.6.25, bsdgroups is supported by ext2, ext3, ext4, and .\" XFS (since 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. .RS .PP Das Argument \fImode\fP legt die Dateimodusbits, die beim Erstellen einer neuen Dateien angewandt werden sollen, fest. Das Argument muss bereitgestellt werden, wenn \fBO_CREAT\fP oder \fBO_TMPFILE\fP in \fIflags\fP festgelegt wird. Falls weder \fBO_CREAT\fP noch \fBO_TMPFILE\fP festgelegt ist, wird \fImode\fP ignoriert. 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\ &\ ~umask)\fP. 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 lese\- und schreibbaren Dateideskriptor zurückliefern. .PP Für \fImode\fP werden die folgenden symbolischen Konstanten bereitgestellt: .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 \fImode\fP gesetzt werden, nicht spezifiziert. Unter Linux werden auch die folgenden Bits in \fImode\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 misbilligte) 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 \fIpathname\fP kein Verzeichnis ist, schlägt damit open fehl. Dieser Schalter wurde in Kernel\-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 festgelegt wird und \fIpathname\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 festgelegt werden, wird symbolischen Links nicht gefolgt. Falls \fIpathname\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 \fIpathname\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 * 3 .\" Strictly speaking: the filesystem UID Die effektive UID des Prozesses passt auf die Eigentümer\-UID des Datei. .IP * 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 \fIpathname\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 \fIpathname\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 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 Aktionen auf dem zurückgegebenen Dateideskriptor werden dazu führen, dass der aufrufende Prozess warten muss. .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 * 3 \fBclose\fP(2). .IP * .\" commit 332a2e1244bd08b9e3ecd378028513396a004a24 \fBfchdir\fP(2), falls der Dateideskriptor auf ein Verzeichnis verweist (seit Linux 3.5). .IP * \fBfstat\fP(2) (seit Linux 3.6). .IP * .\" fstat(): commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 .\" fstatfs(): commit 9d05746e7b16d8565dddbe3200faa1e669d23bbf \fBfstatfs\fP(2) (seit Linux 3.12). .IP * Duplizieren des Dateideskriptors (\fBdup\fP(2), \fBfcntl\fP(2) \fBF_DUPFD\fP, usw.). .IP * Ermitteln und Setzen von Dateideskriptorenschaltern (\fBfcntl\fP(2) \fBF_GETFD\fP und \fBF_SETFD\fP). .IP * 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 * Übergabe des Dateideskriptors als Argument \fIdirfd\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 * Ü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 \fIflags\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 \fIpathname\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 \fIdirfd\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 If \fIpathname\fP refers to an automount point that has not yet been triggered, so no other filesystem is mounted on it, then the call returns a file descriptor referring to the automount directory without triggering a mount. \fBfstatfs\fP(2) can then be used to determine if it is, in fact, an untriggered automount point (\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 \fIpathname\fP legt ein Verzeichnis fest; ein unbenannter Inode wird in dem Dateisystem dieses Verzeichnisses erstellt. Alles, was in die entstandene Datei geschrieben wird, geht verloren, wenn der letzte Dateideskriptor geschlossen wird, sofern der Datei nicht ein Name gegeben wurde. .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/zu/Verz", O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR); /* Datei\-E/A auf »fd«… */ snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd); linkat(AT_FDCWD, path, AT_FDCWD, "/Pfad/zur/Datei", AT_SYMLINK_FOLLOW); .EE .in .IP In diesem Fall bestimmt das Argument \fImode\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 * 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 * 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 Shmem bereitgestellt. Die Unterstützung für weitere Dateisysteme wurde später wie folgt hinzugefügt: XFS (Linux 3.15), Btrfs (Linux 3.16), F2FS (Linux 3.16) und Ubifs (Linux 4.9). .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 \fIflags\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. .PP Falls der in \fIpathname\fP angegebene Pfadname relativ ist, dann wird er relativ zu dem Verzeichnis interpretiert, auf das der Dateideskriptor \fIdirfd\fP verweist (statt relativ zu dem aktuellen Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei \fBopen\fP() für einen relativen Pfadnamen erfolgt). .PP Falls \fIpathname\fP relativ ist und \fIdirfd\fP den speziellen Wert \fBAT_FDCWD\fP enthält, dann wird \fIpathname\fP relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie \fBopen\fP()). .PP Falls \fIpathname\fP absolut ist wird \fIdirfd\fP ignoriert. .SH RÜCKGABEWERT \fBopen\fP(), \fBopenat\fP() und \fBcreat\fP() liefern den neuen Dateideskriptor zurück oder \-1, falls ein Fehler auftrat (in diesem Fall wird \fIerrno\fP entsprechend gesetzt). .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 \fIpathname\fP verweigert oder die Datei existierte noch nicht oder Schreibzugriff auf das Elternverzeichnis ist nicht erlaubt. (Siehe auch \fBpath_resolution\fP(7).) .TP \fBEDQUOT\fP Wo \fBO_CREAT\fP angegeben ist existiert die Datei nicht und die Quota des Benutzers an Plattenblöcken oder Inodes auf dem Dateisystem ist erschöpft. .TP \fBEEXIST\fP \fIpathname\fP existiert bereits und \fBO_CREAT\fP und \fBO_EXCL\fP wurden verwandt. .TP \fBEFAULT\fP \fIpathname\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 \fIflags\fP angegeben, aber weder \fBO_WRONLY\fP noch \fBO_RDWR\fP wurden angegeben. .TP \fBEINVAL\fP \fBO_CREAT\fP wurde in \fIflags\fP angegeben und die abschließende Komponente (»basename«) des \fIpathname\fP der neuen Datei ist ungültig (d.h. sie enthält im unterliegenden Dateisystem nicht erlaubte Zeichen). .TP \fBEISDIR\fP \fIpathname\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 \fIpathname\fP bezieht sich auf ein existierendes Verzeichnis, \fBO_TMPFILE\fP und entweder \fBO_WRONLY\fP oder \fBO_RDWR\fP wurde in \fIflags\fP angegeben, aber diese Kernelversion stellt die Funktionalität \fBO_TMPFILE\fP nicht zur Verfügung. .TP \fBELOOP\fP Bei der Auflösung von \fIpathname\fP wurden zu viele symbolische Links gefunden. .TP \fBELOOP\fP \fIpathname\fP war ein symbolischer Link und \fIflags\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 \fIpathname\fP war zu lang. .TP \fBENFILE\fP Die systemweite Beschränkung für die Gesamtzahl offener Dateien wurde erreicht. .TP \fBENODEV\fP \fIpathname\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 benannte Datei existiert nicht. Oder ein Verzeichnisteil in \fIpathname\fP existiert nicht oder ist ein toter symbolischer Link. .TP \fBENOENT\fP \fIpathname\fP bezieht sich auf ein nicht existierendes Verzeichnis, \fBO_TMPFILE\fP und entweder \fBO_WRONLY\fP oder \fBO_RDWR\fP wurde in \fIflags\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 \fIpathname\fP sollte erstellt werden, aber das Gerät, das \fIpathname\fP enthält, hat für die neue Datei keinen Platz. .TP \fBENOTDIR\fP Eine als Verzeichnis verwandte Komponente in \fIpathname\fP ist tatsächlich kein Verzeichnis oder \fBO_DIRECTORY\fP wurde angegeben, aber \fIpathname\fP war kein Verzeichnis. .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 \fBEOPNOTSUPP\fP Das Dateisystem, das \fIpathname\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 \fIpathname\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 Kerneln 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 festgelegt, 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 \fIpathname\fP bezieht sich auf eine Datei auf einem schreibgeschützten Dateisystem, und Schreibzugriff wurde angefordert. .TP \fBETXTBSY\fP \fIpathname\fP bezieht sich auf ein ausführbares Abbild, das derzeit ausgeführt wird und Schreibzugriff wurde erbeten. .TP \fBETXTBSY\fP \fIpathname\fP bezieht sich auf eine Datei, die derzeit als Auslagerungsdatei verwandt wird und \fBO_TRUNC\fP wurde festgelegt. .TP \fBETXTBSY\fP \fIpathname\fP bezieht sich auf ein 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)). .PP Die folgenden zusätzlichen Fehler können bei \fBopenat\fP() auftreten: .TP \fBEBADF\fP \fIdirfd\fP ist kein zulässiger Dateideskriptor. .TP \fBENOTDIR\fP \fIpathname\fP ist ein relativer Pfadname und \fIdirfd\fP ist ein Dateideskriptor, der sich auf eine Datei statt auf ein Verzeichnis bezieht. .SH VERSIONEN \fBopenat\fP() wurde zu Linux in Kernel 2.6.16 hinzugefügt; Bibliotheksunterstützung wurde zu Glibc in Version 2.4 hinzugefügt. .SH "KONFORM ZU" \fBopen\fP(), \fBcreat\fP() SVr4, 4.3BSD, POSIX.1\-2001, POSIX.1\-2008. .PP \fBopenat\fP(): POSIX.1\-2008. .PP 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. .PP 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. .PP Wie in \fBfeature_test_macros\fP(7) angemerkt, müssen Feature\-Test\-Makros wie \fB_POSIX_C_SOURCE\fP, \fB_XOPEN_SOURCE\fP und \fB_GNU_SOURCE\fP definiert werden, bevor \fIirgendeine\fP Header\-Datei mit »include« verwandt wird. .SH ANMERKUNGEN Unter Linux gibt der Schalter \fBO_NONBLOCK\fP an, dass die Datei geöffnet werden soll, ohne aber notwendigerweise zu lesen oder zu schreiben. Dies wird typischerweise zum Öffnen von Geräten verwandt, um den Dateideskriptor für \fBioctl\fP(2) zu erhalten. .PP .\" 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. .PP Beachten Sie, dass \fBopen\fP() Spezial\-Gerätedateien öffnen kann, aber \fBcreat\fP() sie nicht erstellen kann. Verwenden Sie stattdessen \fBmknod\fP(2). .PP 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. .PP .\" .\" Die Dateien im Verzeichnis \fI/proc/[PID]/fd\fP zeigen die offenen Dateideskriptoren des Prozesses mit der PID \fIPID\fP. Die Dateien im Verzeichnis \fI/proc/[PID]/fdinfo\fP zeigen noch mehr Informationen über diese Dateideskriptoren. Siehe \fBproc\fP(5) für weitere Details über beide Verzeichnisse. .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. .PP 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. .PP Jedes \fBopen\fP() einer Datei erstellt eine neue offene Dateideskription; daher kann es mehrere offene Dateideskriptionen geben, die einem Datei\-Inode entsprechen. .PP .\" .\" 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 "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. .PP 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.) .PP \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. .PP 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). .PP 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). .PP .\" 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 pre\-2.6.33\-Kerneln 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. .SS NFS Es gibt mehrere Unglücklichkeiten im Protokoll, das NFS unterliegt, die unter anderem \fBO_SYNC\fP und \fBO_NDELAY\fP betreffen. .PP .\" .\" 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 \fIflags\fP festgelegt 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 \fIflags\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. .PP .\" 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 \fIflags\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), \fBfstatat\fP(2), \fBfutimesat\fP(2), \fBlinkat\fP(2), \fBmkdirat\fP(2), \fBmknodat\fP(2), \fBname_to_handle_at\fP(2), \fBreadlinkat\fP(2), \fBrenameat\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. .PP 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 \fIdirfd\fP von (beispielsweise) \fBfstatat\fP(2) und \fBopenat\fP() verwandt wird. Die Verwendung des Dateideskriptors \fIdirfd\fP hat auch weitere Vorteile: .IP * 3 Der Dateideskriptor ist eine stabile Referenz zu dem Verzeichnis, selbst falls das Verzeichnis umbenannt wird. .IP * Der offene Dateideskriptor verhindert, dass das darunterliegende Dateisystem ausgehängt wird, genauso als wenn ein Prozess sein aktuelles Arbeitsverzeichnis auf dem Dateisystem hat. .PP .\" .\" 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/\fPdirfd erreicht werden.) .SS O_DIRECT .PP 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. Es gibt jedoch derzeit keine dateisystemunabhängige Schnittstelle für eine Anwendung, um diese Beschränkungen für eine gegebene Datei oder ein Dateisystem aufzufinden. Einige Dateisysteme stellen zu diesem Zweck ihre eigenen Schnittstellen bereit, beispielsweise die Aktion \fBXFS_IOC_DIOINFO\fP in \fBxfsctl\fP(3). .PP Unter Linux 2.4 müssen Übertragungsgrößen, die Ausrichtung des Benutzerpuffers und der Dateiversatz Vielfache der logischen Blockgröße des Dateisystems sein. Seit Linux 2.6.0 reicht ein Ausrichtung an der logischen Blockgröße des darunterliegenden Speichers (normalerweise 512 byte) aus. Die logische Blockgröße kann mit der Aktion \fBBLKSSZGET\fP von \fBioctl\fP(2) festgelegt werden oder mittels des Shell\-Befehls: .PP .EX blockdev \-\-getss .EE .PP \fBO_DIRECT\fP I/Os should never be run concurrently with the \fBfork\fP(2) system call, if the memory buffer is a private mapping (i.e., any mapping created with the \fBmmap\fP(2) \fBMAP_PRIVATE\fP flag; this includes memory allocated on the heap and statically allocated buffers). Any such I/Os, whether submitted via an asynchronous I/O interface or from another thread in the process, should be completed before \fBfork\fP(2) is called. Failure to do so can result in data corruption and undefined behavior in parent and child processes. This restriction does not apply when the memory buffer for the \fBO_DIRECT\fP I/Os was created using \fBshmat\fP(2) or \fBmmap\fP(2) with the \fBMAP_SHARED\fP flag. Nor does this restriction apply when the memory buffer has been advised as \fBMADV_DONTFORK\fP with \fBmadvise\fP(2), ensuring that it will not be available to the child after \fBfork\fP(2). .PP 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. .PP Die Unterstützung für \fBO_DIRECT\fP wurde unter Linux in Kernel Version 2.4.10 hinzugefügt. Ältere Kernel werden diesen Schalter einfach ignorieren. Einige Dateisysteme könnten den Schalter nicht implementieren. In diesem Fall schlägt \fBopen\fP() mit dem Fehler \fBEINVAL\fP fehl, falls er verwandt wird. .PP 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. .PP 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. .PP 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. .PP .RS »Was mich immer bei O_DIRECT beunruhigt hat, ist, dass die gesamte Schnittstelle einfach nur dumm ist, und wahrscheinlich von einem geistesgestörten Affen unter dem Einfluss ernsthafter gedächtnisbeeinflussender Substanzen entwickelt wurde.« – Linus .RE .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. .PP 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. .PP Wenn sowohl \fBO_CREAT\fP als auch \fBO_DIRECTORY\fP in \fIflags\fP angegeben sind und die durch \fIpathname\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), \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) .SH KOLOPHON Diese Seite ist Teil der Veröffentlichung 4.16 des Projekts Linux\-\fIman\-pages\fP. Eine Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden sich unter \%https://www.kernel.org/doc/man\-pages/. .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Note: File description → Dateideskription, Mario Blättermann , Chris Leick , Dr. Tobias Quathamer und Helge Kreutzmann erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an .