OPEN(2) | Linux-Programmierhandbuch | OPEN(2) |
open, openat, creat - eine Datei öffnen und möglicherweise erzeugen
#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h>
int open(const char *Pfadname, int Schalter); int open(const char *Pfadname, int Schalter, mode_t Modus);
int creat(const char *Pfadname, mode_t Modus);
int openat(int Verzdd, const char *Pfadname, int Schalter); int openat(int Verzdd, const char *Pfadname, int Schalter, mode_t Modus);
/* Separat in openat2(2) dokumentiert: */ int openat2(int Verzdd, const char *Pfadname, const struct open_how *wie, size_t Größe);
openat():
Der Systemaufruf open() öffnet eine durch Pfadname angegebene Datei. Falls die angegebene Datei nicht existiert, kann sie optional (falls O_CREAT in Schalter angegeben wurde) durch open() erstellt werden.
Der Rückgabewert von open() ist ein Dateideskriptor, eine kleine, nicht negative Ganzzahl, die in nachfolgenden Systemaufrufen (read(2), write(2), lseek(2), fcntl(2) usw.) genutzt wird, um den Bezug zu der offenen Datei herzustellen. Der bei einem erfolgreichen Aufruf zurückgelieferte Dateideskriptor wird der niedrigstzahlige, noch nicht für den Prozess offene Dateideskriptor sein.
Standardmäßig bleibt der neue Dateideskriptor über ein execve(2) offen (d.h. der in fcntl(2) beschriebene Dateideskriptorschalter FD_CLOEXEC ist anfangs leer). Der weiter unten beschriebene Schalter O_CLOEXEC kann zum Ändern dieser Vorgabe verwandt werden. Der Dateiversatz wird auf den Anfang der Datei gesetzt (siehe lseek(2)).
Ein Aufruf von open() erstellt eine neue offene Dateideskription, einen Entrag in der systemweiten Tabelle von offenen Dateien. Die offene Dateideskription zeichnet den Dateiversatz und die Dateizustandsschalter (siehe unten) auf. Ein Dateideskriptor ist eine Referenz auf eine offene Dateideskription. Diese Referenz ist nicht betroffen, falls Pfadname im Folgenden entfernt oder so verändert wird, dass er auf eine andere Datei zeigt. Für weitere Details über offene Dateideskriptionen, siehe ANMERKUNGEN.
Das Argument Schalter muss einen der folgenden Zugriffsmodi enthalten: O_RDONLY, O_WRONLY oder O_RDWR. Diese erbitten, die Datei nur lesbar, nur schreibbar bzw. les-/schreibbar zu öffnen.
Zusätzlich können Null oder mehr Dateierstellungsschalter in Schalter mit einem bitweisen Oder zusammengebracht werden. Die Dateierstellungsschalter sind O_CLOEXEC, O_CREAT, O_DIRECTORY, O_EXCL, O_NOCTTY, O_NOFOLLOW, O_TMPFILE und O_TRUNC. Die restlichen unten aufgeführten Schalter sind die Dateistatusschalter. Der Unterschied zwischen diesen zwei Gruppen von Schaltern besteht darin, dass die Dateierstellungsschalter die Semantik der Open-Aktion selbst betreffen, während die Dateistatusschalter die Semantik der nachfolgenden E/A-Aktionen betreffen. Die Dateistatussschalter können abgefragt und (in einigen Fällen) verändert werden; siehe fcntl(2) für Details.
Die komplette Liste der Dateierstellungs- und Dateistatusschalter ist wie folgt:
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);
char path[PATH_MAX]; fd = open("/Pfad/zu/Verz", O_TMPFILE | O_RDWR,
S_IRUSR | S_IWUSR); /* Datei-E/A auf »fd«… */ linkat(fd, NULL, AT_FDCWD, "/Pfad/zur/Datei", AT_EMPTY_PATH); /* Falls der Aufrufende nicht über die Capability CAP_DAC_READ_SEARCH
verfügt (benötigt, um AT_EMPTY_PATH mit linkat(2) zu verwenden) und ein
proc(5)-Dateisystem eingehängt ist, dann kann obiger linkat(2)-Aufruf
mit Folgendem ersetzt werden: snprintf(path, PATH_MAX, "/proc/self/fd/%d", fd); linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
AT_SYMLINK_FOLLOW); */
Ein Aufruf von creat() is äquivalent zum Aufruf von open() mit Schalter identisch zu O_CREAT|O_WRONLY|O_TRUNC.
Der Systemaufruf openat() arbeitet genau wie open(), außer den hier beschriebenen Unterschieden.
Falls der in Pfadname angegebene Pfadname relativ ist, dann wird er relativ zu dem Verzeichnis interpretiert, auf das der Dateideskriptor Verzdd verweist (statt relativ zu dem aktuellen Arbeitsverzeichnis des aufrufenden Prozesses, wie es bei open() für einen relativen Pfadnamen erfolgt).
Falls Pfadname relativ ist und Verzdd den speziellen Wert AT_FDCWD enthält, dann wird Pfadname relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie open()).
Falls Pfadname absolut ist, wird Verzdd ignoriert.
Der Systemaufruf openat2(2) ist eine Erweiterung von openat() und stellt eine Obermenge der Funtionalitäten von openat() zur Verfügung. Er ist separat in openat2(2) dokumentiert.
open(), openat() und creat() liefern den neuen Dateideskriptor zurück (eine nicht negative Ganzzahl) oder -1, falls ein Fehler auftrat (in diesem Fall wird errno entsprechend gesetzt).
open(), openat() und creat() können mit den folgenden Fehlern fehlschlagen:
Die folgenden zusätzlichen Fehler können bei openat() auftreten:
openat() wurde zu Linux in Kernel 2.6.16 hinzugefügt; Bibliotheksunterstützung wurde zu Glibc in Version 2.4 hinzugefügt.
open(), creat() SVr4, 4.3BSD, POSIX.1-2001, POSIX.1-2008.
openat(): POSIX.1-2008.
openat2(2) ist Linux-spezifisch.
Die Schalter O_DIRECT, O_NOATIME, O_PATH und O_TMPFILE sind Linux-spezifisch. Sie müssen _GNU_SOURCE definieren, um ihre Definitionen zu erhalten.
Die Schalter O_CLOEXEC, O_DIRECTORY und O_NOFOLLOW sind nicht in POSIX.1-2001 sondern in POSIX.1-2008 spezifiziert. Seit Glibc 2.12 kann ihre Definition erhalten werden, indem entweder _POSIX_C_SOURCE mit einem Wert größer als oder identisch zu 200809L definiert wird oder durch _XOPEN_SOURCE mit einem Wert größer als oder identisch zu 700. In Glibc 2.11 und älter kann die Definition über die Definition von _GNU_SOURCE erhalten werden.
Wie in feature_test_macros(7) angemerkt, müssen Feature-Test-Makros wie _POSIX_C_SOURCE, _XOPEN_SOURCE und _GNU_SOURCE definiert werden, bevor irgendeine Header-Datei mit »include« verwandt wird.
Unter Linux wird der Schalter O_NONBLOCK manchmal in Fällen benutzt, in denen die Datei geöffnet werden soll, ohne aber notwendigerweise zu lesen oder zu schreiben. Beispielsweise kann dies dazu verwandt werden, ein Gerät zu öffnen, um einen Dateideskriptor für ioctl(2) zu erhalten.
Der (undefinierte) Effekt von O_RDONLY | O_TRUNC unterscheidet sich in vielen Implementierungen. Auf vielen Systemen wird die Datei tatsächlich abgeschnitten.
Beachten Sie, dass open() Spezial-Gerätedateien öffnen kann, aber creat() sie nicht erstellen kann. Verwenden Sie stattdessen mknod(2).
Falls die Datei neu erstellt wurde, werden ihre Felder st_atime, st_ctime, st_mtime (Zeit des letzten Zugriffs, Zeit der letzten Statusänderung und Zeit der letzten Änderung, siehe stat(2)) auf die aktuelle Zeit gesetzt und ebenso die Felder st_ctime und st_mtime des Elternverzeichnisses. Andernfalls, falls die Datei aufgrund des Schalters O_TRUNC geändert wurde, werden ihre Felder st_ctime und st_mtime auf die aktuelle Zeit gesetzt.
Die Dateien im Verzeichnis /proc/[PID]/fd zeigen die offenen Dateideskriptoren des Prozesses mit der PID PID. Die Dateien im Verzeichnis /proc/[PID]/fdinfo zeigen noch mehr Informationen über diese Dateideskriptoren. Siehe proc(5) für weitere Details über beide Verzeichnisse.
Die Linux-Header-Datei <asm/fcntl.h> definiert O_ASYNC nicht, es wird stattdessen das (von BSD abgeleitete) Synonym FASYNC definiert.
Der Begriff offene Dateideskription wird von POSIX verwandt, um sich auf Einträge in der systemweiten Tabelle der offenen Dateien zu beziehen. In anderen Zusammenhängen wird dieses Objekt verschieden auch »offenes Dateiobjekt«, »Datei-Handle«, »offener Dateitabelleneintrag« oder – in der Sprache der Kernel-Entwickler – struct file genannt.
Wenn ein Dateideskriptor (mit dup(2) oder ähnlichem) dupliziert wird, bezieht sich das Duplikat auf die gleiche offene Dateideskription wie der ursprüngliche Datedeskriptor und die zwei Dateideskriptoren haben konsequenterweise den gleichen Dateiversatz und die gleichen Dateistatusschalter. Solch ein gemeinsamer Satz kann auch zwischen Prozessen auftreten: ein mit fork(2) erstellter Kindprozess erbt Duplikate der Dateideskriptoren seines Elternprozesses und diese Duplikate beziehen sich auf die gleichen offenen Dateideskriptoren.
Jedes open() einer Datei erstellt eine neue offene Dateideskription; daher kann es mehrere offene Dateideskriptionen geben, die einem Datei-Inode entsprechen.
Unter Linux kann die Aktion KCMP_FILE von kcmp(2) zum Testen, ob sich zwei Dateideskriptoren (in dem gleichen Prozess oder in zwei verschiedenen Prozessen) auf die gleiche offene Dateideskription beziehen, verwandt werden.
Die Option »synchronisierte E/A« von POSIX.1-2008 spezifiziert verschiedene Varianten der synchronisierten E/A und spezifiziert Schalter O_SYNC, O_DSYNC und O_RSYNC von open() für die Steuerung des Verhaltens. Unabhängig davon, ob eine Implementierung diese Option unterstützt muss sie mindestens die Verwendung von O_SYNC für reguläre Dateien unterstützen.
Linux implementiert O_SYNC und O_DSYNC, aber nicht O_RSYNC. Etwas inkorrekt definiert Glibc O_RSYNC auf den gleichen Wert wie O_SYNC. (O_RSYNC wird auf HP PA-RISC in der Linux-Header-Datei <asm/fcntl.h> definiert, aber nicht benutzt.)
O_SYNC stellt synchronisierte E/A-Datei-Integritätsvervollständigung bereit. Das bedeutet, Schreibaktionen schieben ihre Daten und zugehörigen Metadaten an die darunterliegende Hardware. O_DSYNC stellt synchronisierte E/A-Daten-Integritätsvervollständigung bereit. Das bedeutet, Schreibaktionen schieben ihre Daten an die darunterliegende Hardware, aber schieben nur Metadatenaktualisierungen, die benötigt werden, um folgende Leseaktionen erfolgreich abzuschließen. Datenintegritätsvervollständigung kann die Anzahl der Aktionen reduzieren, die für Anwendungen notwendig werden, die keine Garantien für die Dateiintegritätsvervollständigung benötigen.
Um den Unterschied zwischen den zwei Arten von Vervollständigung zu verstehen, betrachen Sie zwei verschiedene Dateimetadaten: den Zeitstempel der letzten Änderung (st_mtime) und die Dateilänge. Alle Schreibaktionen aktualisieren den Zeitstempel der letzten Dateiänderung, aber nur Schreibaktionen, die Daten am Ende der Datei hinzufügen, müssen die Dateilänge ändern. Der Zeitstempel der letzten Änderung wird nicht benötigt, um sicherzustellen, dass eine Leseaktion erfolgreich abgeschlossen werden kann, aber die Dateilänge wird dafür benötigt. Daher würde O_DSYNC nur garantieren, dass Aktualisierungen der Dateilängen-Metadaten rausgeschoben werden (während O_SYNC immer auch das Metadatum des Zeitstempels der letzten Änderung rausschieben würde).
Vor Linux 2.6.33 implementierte Linux nur den Schalter O_SYNC für open(). Als dieser Schalter spezifiziert wurde, stellten die meisten Dateisysteme das Äquivalent von synchronisierter E/A-Daten-Integritätsvervollständigung bereit (d.h. O_SYNC war tatsächlich als Äquivalent von O_DSYNC implementiert).
Seit Linux 2.6.33 wird korrekte Unterstützung für O_SYNC bereitgestellt. Um Rückwärtskompatibilität sicherzustellen wurde aber O_DSYNC mit dem gleichen Wert wie das historische O_SYNC definiert und O_SYNC wurde als neuer (Zweibit-)Schalterwert definiert, der den Wert des Schalters O_DSYNC enthält. Das stellt sicher, dass Anwendungen, die gegen neue Header übersetzt wurden, mindestens die Semantik von O_DSYNC auf pre-2.6.33-Kerneln erhalten.
Seit Version 2.26 setzt die Glibc-Wrapper-Funktion für open() den Systemaufruf openat() statt des Systemaufrufs open() des Kernels ein. Für bestimmte Architekturen stimmt dies auch für Glibc-Versionen vor 2.26.
Es gibt mehrere Unglücklichkeiten im Protokoll, das NFS unterliegt, die unter anderem O_SYNC und O_NDELAY betreffen.
Auf NFS-Dateisystemen mit aktivierter UID-Abbildung könnte open() einen Dateideskriptor zurückliefern, aber read(2)-Anfragen werden beispielsweise mit EACCES verweigert. Dies erfolgt, da der Client open() durchführt, indem er die Rechte prüft, aber die UID-Abbildung auf dem Server bei Lese- und Schreibanfragen erfolgt.
Öffnen des Lese- oder Schreibendes eines FIFOS blockiert, bis das andere Ende auch geöffnet wurde (durch einen anderen Prozess oder Thread). Siehe fifo(7) für weitere Details.
Anders als andere Werte, die in Schalter angegeben werden können, legen die Zugriffsmodus-Werte O_RDONLY, O_WRONLY und O_RDWR nicht individuelle Bits fest. Stattdessen definieren sie die untersten zwei Bits von Schalter und sind respektive als 0, 1 und 2 definiert. Mit anderen Worten, die Kombination O_RDONLY | O_WRONLY ist ein logischer Fehler und hat bestimmt nicht die gleiche Bedeutung wie O_RDWR.
Linux reserviert den besonderen, nicht standardisierten Zugriffsmodus 3 (binär 11) in Schalter für folgendes: Prüfe auf Lese- und Schreibberechtigung der Datei und liefere einen Dateideskriptor zurück, der weder zum Lesen noch zum Schreiben verwandt werden kann. Dieser nicht standardisierte Zugriffsmodus wird von einigen Linux-Treibern verwandt, um einen Dateideskriptor zurückzuliefern, der nur für gerätespezifische ioctl(2)-Aktionen benutzt werden kann.
openat() und andere Systemaufrufe und Bibliotheksfunktionen, die ein Verzeichnis-Dateideskriptor als Argument akzeptieren (d.h. execveat(2), faccessat(2), fanotify_mark(2), fchmodat(2), fchownat(2), fspick(2), fstatat(2), futimesat(2), linkat(2), mkdirat(2), move_mount(2), mknodat(2), name_to_handle_at(2), open_tree(2), openat2(2), readlinkat(2), renameat(2), statx(2), symlinkat(2), unlinkat(2), utimensat(2), mkfifoat(3) und scandirat(3)) behandeln zwei Probleme mit der älteren Schnittstelle, die dieser voranging. Hier erfolgt die Erläuterung am openat()-Aufruf, aber der Grund ist analog für die anderen Schnittstellen.
Erstens erlaubt openat() es Anwendungen, Race-Conditions zu vermeiden, die bei der Verwendung von open() auftreten können, wenn Dateien geöffnet werden, die sich nicht im lokalen Verzeichnis befinden. Diese Race-Conditions entstammen der Tatsache, dass einige Komponenten des Verzeichnispräfixes, der an open() übergeben wird, parallel zum Aufruf von open() geändert werden können. Nehmen Sie beispielsweise an, dass Sie die Datei dir1/dir2/xxx.dep öffnen möchten, falls dir1/dir2/xxx existiert. Das Problem besteht darin, das sich zwischen der Existenzüberprüfung und dem Schritt der Dateierstellung dir1 oder dir2 (die symbolischen Links sein können) geändert haben und auf einen anderen Ort zeigen können. Solche Ressourcenwettläufe können vermieden werden, indem ein Dateideskriptor für das Zielverzeichnis geöffnet wird und dann dieser Dateideskriptor als Argument Verzdd von (beispielsweise) fstatat(2) und openat() verwandt wird. Die Verwendung des Dateideskriptors Verzdd hat auch weitere Vorteile:
Zweitens erlaubt openat() die Implementierung eines pro-Thread-»Arbeitsverzeichnisses«, mittels von der Anwendung verwalteten Datei-Deskriptor(en). (Diese Funktionalität kann weniger effizient auch mittels Tricks basierend auf der Verwendung von /proc/self/fd/dirfd erreicht werden.)
Das Argument Verzdd für diese APIs kann mittels open() oder openat() zum Öffnen eines Verzeichnisses erhalten werden (mit entweder dem Schalter O_RDONLY oder O_PATH). Alternativ kann ein solcher Dateideskriptor durch Anwendung von dirfd(3) auf einen mittels opendir(3) erzeugten Verzeichnisdatenstrom erhalten werden.
Wird diesen APIs ein Verzdd-Argument von AT_FDCWD übergeben oder der angegebene Pfadname ist absolut, dann handhaben sie ihr Pfadnamenargument auf die gleiche Art wie entsprechende konventionelle APIs. In diesem Fall haben allerdings mehrere der APIs das Argument Schalter, das Zugriff auf die Funktionalität gewährt, die mit den entsprechenden konventionellen APIs nicht verfügbar ist.
Der Schalter O_DIRECT könnte Ausrichtungsbeschränkungen in der Länge und Adresse der Puffer in der Anwendungsebene und dem Dateiversatz von E/As verhängen. Unter Linux variieren die Ausrichtungsbeschränkungen je nach Dateisystem und Kernelversion und können auch ganz fehlen. Es gibt jedoch derzeit keine dateisystemunabhängige Schnittstelle für eine Anwendung, um diese Beschränkungen für eine gegebene Datei oder ein Dateisystem aufzufinden. Einige Dateisysteme stellen zu diesem Zweck ihre eigenen Schnittstellen bereit, beispielsweise die Aktion XFS_IOC_DIOINFO in xfsctl(3).
Unter Linux 2.4 müssen Übertragungsgrößen, die Ausrichtung des Benutzerpuffers und der Dateiversatz Vielfache der logischen Blockgröße des Dateisystems sein. Seit Linux 2.6.0 reicht ein Ausrichtung an der logischen Blockgröße des darunterliegenden Speichers (normalerweise 512 byte) aus. Die logische Blockgröße kann mit der Aktion BLKSSZGET von ioctl(2) festgelegt werden oder mittels des Shell-Befehls:
blockdev --getss
O_DIRECT-E/As sollten niemals gleichzeitig mit dem Systemaufruf fork(2) ausgeführt werden, falls der Speicherpuffer ein privates Mapping ist (das heißt, jede mit dem Schalter MAP_PRIVATE von mmap(2) erzeugtes Mapping; dies beinhaltet im Heap zugewiesenen Speicher und statisch zugewiesene Puffer). Und solche E/As, ganz gleich ob über eine asynchrone E/A-Schnittstelle oder über einen anderen Thread im Prozess übergeben, sollten abgeschlossen sein, bevor fork(2) aufgerufen wird. Tun Sie dies nicht, kann Beschädigung von Daten und undefiniertes Verhalten in Eltern- und Kindprozessen die Folge sein. Diese Einschränkung gilt nicht, wenn der Speicherpuffer für die O_DIRECT-E/As mittels shmat(2) oder mmap(2) mit dem Schalter MAP_SHARED erzeugt wurde. Außerdem gilt die Einschränkung nicht, wenn der Speicherpuffer mit madvise(2) als MADV_DONTFORK deklariert wurde, was sicherstellt, dass es nach dem Aufruf von fork(2) für den Kindprozess nicht verfügbar ist.
Der Schalter O_DIRECT wurde in SGI IRIX eingeführt, wo er Ausrichtungsbeschränkungen hat, die denen von Linux 2.4 ähnlich sind. IRIX hat außerdem einen fcntl(2)-Aufruf, um geeignete Ausrichtungen und Größen abzufragen. FreeBSD 4.x führte einen gleichnamigen Schalter ein, jedoch ohne Ausrichtungsbeschränkungen.
Die Unterstützung für O_DIRECT wurde unter Linux in Kernel Version 2.4.10 hinzugefügt. Ältere Kernel werden diesen Schalter einfach ignorieren. Einige Dateisysteme könnten den Schalter nicht implementieren. In diesem Fall schlägt open() mit dem Fehler EINVAL fehl, falls er verwandt wird.
Anwendungen sollten das Vermischen von O_DIRECT und normaler E/A auf der gleichen Datei vermeiden, insbesondere für überlappende Regionen in der gleichen Datei. Selbst wenn das Dateisystem die Kohärenzprobleme in dieser Situation korrekt handhabt, ist der Gesamt-E/A-Durchsatz wahrscheinlich geringer, als wenn einer der beiden Modi allein verwandt worden wäre. Entsprechend sollten Anwendungen das Mischen von mmap(2) von Dateien mit direktem E/A auf die gleichen Dateien vermeiden.
Das Verhalten von O_DIRECT mit NFS wird sich vom lokalen Dateisystem unterscheiden. Ältere Kernel oder Kernel, die in bestimmter Weise konfiguriert wurden, unterstützen diese Kombination möglicherweise nicht. Das NFS-Protokoll unterstützt die Übergabe des Schalters an den Server nicht, daher wird O_DIRECT-E/A den Seitenzwischenspeicher auf dem Client umgehen. Der Server könnte weiterhin die E/A zwischenspeichern. Der Client bittet den Server, die E/A zu synchronisieren, damit die synchrone Semantik von O_DIRECT aufrechterhalten wird. Einige Server werden unter diesen Umständen unzureichende Leistung erbringen, insbesondere bei kleiner E/A-Größe. Einige Server sind möglicherweise auch so konfiguriert, dass sie ihre Clients darüber belügen, dass die E/A stabilen Speicher erreicht haben. Dies wird die Leistungseinbuße bei gleichzeitigem Risiko der Datenintegrität im Fall eines Stromausfalls verhindern. Der Linux-NFS-Client legt keine Ausrichtungsbeschränkungen bei O_DIRECT-E/A fest.
In Zusammenfassung: O_DIRECT ist ein extrem leistungsfähiges Werkzeug, das mit Vorsicht verwandt werden sollte. Es wird empfohlen, dass Anwendungen die Verwendung von O_DIRECT als Leistungssteigerungsoption betrachten, die standardmäßig deaktiviert ist.
Derzeit ist es nicht möglich, Signal-getriebene E/A zu aktivieren, indem O_ASYNC beim Aufruf von open() verwandt wird; siehe fcntl(2), um diesen Schalter zu aktivieren.
Es muss auf zwei verschiedene Fehler-Codes, EISDIR und ENOENT geprüft werden, wenn versucht wird, zu bestimmen, ob der Kernel die Funktionalität O_TMPFILE unterstützt.
Wenn sowohl O_CREAT als auch O_DIRECTORY in Schalter angegeben sind und die durch Pfadname angegebene Datei nicht existiert, wird open() eine normale Datei erstellen (d.h. O_DIRECTORY wird ignoriert).
chmod(2), chown(2), close(2), dup(2), fcntl(2), link(2), lseek(2), mknod(2), mmap(2), mount(2), open_by_handle_at(2), openat2(2), read(2), socket(2), stat(2), umask(2), unlink(2), write(2), fopen(3), acl(5), fifo(7), inode(7), path_resolution(7), symlink(7)
Diese Seite ist Teil der Veröffentlichung 5.10 des Projekts Linux-man-pages. Eine Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.
Die deutsche Übersetzung dieser Handbuchseite wurde von Mario Blättermann <mario.blaettermann@gmail.com>, Chris Leick <c.leick@vollbio.de>, Dr. Tobias Quathamer <toddy@debian.org> und Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.
1. November 2020 | Linux |