Ubuntu Manpage: mknod, mknodat - erstellt eine reguläre oder eine Spezialdatei

BEZEICHNUNG

       mknod, mknodat - erstellt eine reguläre oder eine Spezialdatei

ÜBERSICHT

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

       int mknod(const char *pathname, mode_t mode, dev_t dev);

       #include <fcntl.h>           /* Definition der AT_*-Konstanten */
       #include <sys/stat.h>

       int mknodat(int dirfd, const char *pathname, mode_t mode, dev_t dev);

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

       mknod():
           _BSD_SOURCE || _SVID_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED

BESCHREIBUNG

       Der  Systemaufruf  mknod()  erstellt einen Dateisystem-Knoten (Datei, Gerätedatei oder FIFO, auch bekannt
       als »named pipe«) namens pathname und mit den Attributen, die in mode und dev angegeben wurden.

       Das Argument mode legt sowohl den anzuwendenden Dateimodus als auch den Typ des zu  erstellenden  Knotens
       fest.  Es  sollte  eine  Verbindung (mittels bitweisem ODER) eines der weiter unten angegebenen Typen und
       einer oder mehr der in stat(2) aufgeführten Dateimodusbits sein.

       Der Dateimodus wird durch die umask des Prozesses auf die übliche  Weise  festgelegt:  Ohne  Standard-ACL
       sind die Zugriffsrechte des erzeugten Knotens also (mode & ~umask).

       Der  Dateityp  muss  aus  S_IFREG,  S_IFCHR,  S_IFBLK  und  S_IFIFO gewählt werden. In dieser Reihenfolge
       bestimmen sie eine reguläre Datei (die leer angelegt wird), eine Gerätedatei für ein  zeichenorientiertes
       Gerät,  eine  Gerätedatei  für ein blockorientiertes Gerät, einen FIFO (named pipe) und schließlich einen
       UNIX Domain Socket. (Der Dateityp null ist äquivalent zu S_IFREG).

       Bei den Typen S_IFCHR und S_IFBLK legt dev die Major- und die Minor-Nummer der neu erzeugten  Gerätedatei
       fest; anderenfalls wird dev ignoriert. (makedev(3) kann helfen, den Wert für dev zu ermitteln.)

       Falls  pathname  schon  existiert  oder  ein  symbolischer Link ist, schlägt dieser Aufruf mit dem Fehler
       EEXIST fehl.

       Der neu erzeugte Knoten läuft unter der effektiven UID des aufrufenden Prozesses. Falls das  Verzeichnis,
       in  dem  sich  der  Knoten  befindet,  das  »set-group-ID«-Bit  gesetzt  hat  oder  das  Dateisystem  mit
       BSD-Gruppensemantik  eingehängt  ist,  erbt  der  neue  Knoten  die  Gruppenrechte   des   übergeordneten
       Verzeichnisses; anderenfalls gehört er der effektiven Gruppen-ID des aufrufenden Prozesses.

   mknodat()
       Der Systemaufruf mknodat() funktioniert genauso wie mknod(), außer den hier beschriebenen Unterschieden.

       Falls der in pathname übergebene Pfadname relativ ist wird er als relativ zu dem im Dateideskriptor dirfd
       referenzierten  Verzeichnis interpretiert (statt relativ zum aktuellen Arbeitsverzeichnis des aufrufenden
       Prozesses, wie es bei mknod() für einen relativen Pfadnamen erfolgt).

       Falls pathname relativ ist und dirfd den besonderen Wert AT_FDCWD annimmt wird pathname als  relativ  zum
       aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie mknod(2)).

       Falls pathname absolut ist wird dirfd ignoriert.

       Lesen Sie openat(2) für eine Beschreibung der Notwendigkeit von mkdirat().

RÜCKGABEWERT

       Bei  Erfolg  geben  mknod()  und  mknodat() null zurück. Bei einem Fehler wird -1 zurückgegeben und errno
       entsprechend gesetzt.

FEHLER

EACCES Das übergeordnete Verzeichnis gibt dem Prozess keine Schreibberechtigung oder eines der
Verzeichnisse im Pfad-Präfix von pathname gewährte keine Suchberechtigung; siehe auch
path_resolution(7).

EDQUOT Das Kontingent des Benutzers an Datenträgerblöcken oder Inodes auf dem Dateisystem ist
ausgeschöpft.

EEXIST pathname existiert bereits. Das umfasst auch den Fall, dass pathname ein symbolischer Link ist -
egal ob der ins Leere weist oder nicht.

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

EINVAL mode verlangte etwas Anderes zu erstellen als eine reguläre Datei, eine Gerätedatei, einen FIFO
oder einen Socket.

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

ENAMETOOLONG
pathname war zu lang.

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

ENOMEM Es war nicht genügend Kernel-Speicher verfügbar.

ENOSPC Das Gerät, welches pathname enthält, hat keinen Platz für den neuen Knoten.

ENOTDIR
Eine als Verzeichnis benutzte Komponente von pathname ist kein Verzeichnis.

EPERM mode verlangte etwas Anderes zu erstellen als eine reguläre Datei, einen FIFO (named pipe) oder
einen UNIX Domain Socket und der Aufrufende ist nicht privilegiert (Linux: ihm fehlt die
CAP_MKNOD-Capability). Dieser Fehler wird auch zurückgegeben, wenn das Dateisystem, das pathname
enthält, den angeforderten Knotentyp nicht unterstützt.

EROFS pathname bezieht sich auf eine Datei auf einem schreibgeschützten Dateisystem.

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

EBADF dirfd ist kein zulässiger Dateideskriptor.

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

VERSIONEN

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

KONFORM ZU

       mknod(): SVr4, 4.4BSD, POSIX.1-2001 (siehe aber auch das Folgende), POSIX.1-2008.

       mknodat(): POSIX.1-2008.

ANMERKUNGEN

       POSIX.1-2001 sagt: »Die einzige portable Verwendung von mknod() ist das Erstellen eines FIFOs. Falls mode
       nicht gleich S_IFIFO ist oder dev ist nicht 0, ist das Verhalten von mknod() unbestimmt«. Trotzdem sollte
       man  heutzutage  für diesen Zweck mknod() niemals verwenden und stattdessen die speziell für diesen Zweck
       bestimmte Funktion mkfifo(3) einsetzen.

       Unter  Linux  kann  mknod()  nicht  zur  Erzeugung  von  Verzeichnissen  verwendet  werden.  Man   sollte
       Verzeichnisse mit mkdir(2) erzeugen.

       Es  gibt in dem NFS zugrunde liegenden Protokoll viele Unzulänglichkeiten. Einige davon betreffen mknod()
       und mknodat(2).

SIEHE AUCH

       chmod(2), chown(2), fcntl(2), mkdir(2), mount(2), socket(2), stat(2),  umask(2),  unlink(2),  makedev(3),
       mkfifo(3), acl(5)  path_resolution(7)

KOLOPHON

       Diese  Seite  ist  Teil  der  Veröffentlichung  4.04  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 http://www.kernel.org/doc/man-pages/.

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Lars J. Brandt  <ljbrandt@jorma.ping.de>,  Martin
       Eberhard  Schauer  <Martin.E.Schauer@gmx.de>,  Mario Blättermann <mario.blaettermann@gmail.com> und Helge
       Kreutzmann <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder  neuer
       bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn  Sie  Fehler  in  der  Übersetzung  dieser  Handbuchseite  finden, schicken Sie bitte eine E-Mail an
       <debian-l10n-german@lists.debian.org>.

Linux                                              7. Mai 2015                                          MKNOD(2)