BEZEICHNUNG

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

BIBLIOTHEK

       Standard-C-Bibliothek (libc, -lc)

ÜBERSICHT

       #include <sys/stat.h>

       int mknod(const char *Pfadname, mode_t Modus, dev_t Gerät);

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

       int mknodat(int dirfd, const char *Pfadname, mode_t Modus, dev_t Gerät);

   Mit Glibc erforderliche Feature-Test-Makros (siehe feature_test_macros(7)):

       mknod():
           _XOPEN_SOURCE >= 500
               || /* Seit Glibc 2.19: */ _DEFAULT_SOURCE
               || /* Glibc <= 2.19: */ _BSD_SOURCE || _SVID_SOURCE

BESCHREIBUNG

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

       Das  Argument  Modus  gibt  sowohl  den  anzuwendenden  Dateimodus als auch den Typ des zu
       erstellenden Knotens an. Es sollte eine Verbindung  (mittels  bitweisem  ODER)  eines  der
       weiter  unten  angegebenen  Typen  und  einer  oder  mehr  der  in  inode(7)  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 (Modus & ~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 Gerät die Major- und die Minor-Nummer der neu
       erzeugten Gerätedatei fest; anderenfalls wird Gerät ignoriert.  (makedev(3)  kann  helfen,
       den Wert für Gerät zu ermitteln.)

       Falls  Pfadname  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   Elternverzeichnisses;   anderenfalls   gehört   er   der  effektiven
       Gruppenkennung des aufrufenden Prozesses.

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

       Falls  der  in  Pfadname  ü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 Pfadname relativ ist und dirfd den besonderen Wert AT_FDCWD  annimmt  wird  Pfadname
       als  relativ zum aktuellen Arbeitsverzeichnis des aufrufenden Prozesses interpretiert (wie
       mknod()).

       Falls Pfadname absolut ist, wird Verzdd 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 gesetzt, um den Fehler anzuzeigen.

FEHLER

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

       EBADF  (mknodat())  Der  Pfadname  ist  relativ,  aber  Verzdd ist weder AT_FDCWD noch ein
              gültiger Dateideskriptor.

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

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

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

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

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

       ENAMETOOLONG
              Pfadname war zu lang.

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

       ENOMEM Es war nicht genügend Kernelspeicher verfügbar.

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

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

       ENOTDIR
              (mknodat()) Pfadname ist relativ und Verzdd ist ein Dateideskriptor, der  sich  auf
              eine Datei bezieht, die kein Verzeichnis ist.

       EPERM  Modus  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  Pfadname  enthält,  den  angeforderten
              Knotentyp nicht unterstützt.

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

VERSIONEN

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

STANDARDS

       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 Modus nicht gleich S_IFIFO ist oder Gerät 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().

SIEHE AUCH

       mknod(1), 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)

ÜBERSETZUNG

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

       Diese Übersetzung ist Freie Dokumentation;  lesen  Sie  die  GNU  General  Public  License
       Version  3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
       Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
       Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.