mknod

MKNOD(2)                   Manuel du programmeur Linux                  MKNOD(2)



NOM
       mknod, mknodat - Créer un fichier (special ou ordinaire)

SYNOPSIS
       #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>           /* Définition des constantes AT_* */
       #include <sys/stat.h>

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

   Exigences de macros de test de fonctionnalités pour la glibc (consulter
   feature_test_macros(7)) :

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

DESCRIPTION
       mknod() crée un nœud du système de fichiers (fichier, fichier spécial de
       périphérique ou tube nommé) appelé pathname, avec les attributs mode et
       dev.

       The mode argument specifies both the file mode to use and the type of
       node to be created.  It should be a combination (using bitwise OR) of one
       of the file types listed below and zero or more of the file mode bits
       listed in inode(7).

       The file mode is modified by the process's umask in the usual way: in the
       absence of a default ACL, the permissions of the created node are (mode &
       ~umask).

       Le type de nœud doit être l'un des suivants S_IFREG, S_IFCHR, S_IFBLK,
       S_IFIFO ou S_IFSOCK pour indiquer respectivement un fichier régulier
       (vide à la création), un fichier spécial mode caractère, un fichier
       spécial mode bloc, un tube nommé (FIFO) ou une socket du domaine UNIX. Un
       type de fichier égal à 0 est équivalent à S_IFREG.

       Si le nœud est de type S_IFCHR or S_IFBLK alors dev doit indiquer les
       numéros majeurs et mineurs du périphérique associé (makedev(3) peut être
       utile pour construire la valeur de dev). Pour les autres types de nœuds,
       dev est ignoré.

       Si pathname existe déjà, ou est un lien symbolique, l'appel échoue avec
       l'erreur EEXIST.

       Le nœud nouvellement créé aura pour propriétaire l'UID effectif du
       processus. Si le répertoire contenant ce nœud a son bit Set-GID à 1, ou
       si le système de fichiers est monté avec une sémantique BSD, le nouveau
       nœud héritera de l'appartenance au groupe de son parent. Sinon il
       appartiendra au groupe effectif du processus.

   mknodat()
       The mknodat()  system call operates in exactly the same way as mknod(),
       except for the differences described here.

       If the pathname given in pathname is relative, then it is interpreted
       relative to the directory referred to by the file descriptor dirfd
       (rather than relative to the current working directory of the calling
       process, as is done by mknod()  for a relative pathname).

       If pathname is relative and dirfd is the special value AT_FDCWD, then
       pathname is interpreted relative to the current working directory of the
       calling process (like mknod()).

       Si pathname est absolu, alors dirfd est ignoré.

       Consultez openat(2) pour une explication de la nécessité de mknodat().

VALEUR RENVOYÉE
       mknod() et mknodat() renvoient 0 si ils réussissent, ou -1 s'ils
       échouent, auquel cas errno contient le code d'erreur.

ERREURS
       EACCES Le répertoire parent n'autorise pas l'écriture au processus, ou
              l'un des répertoires de pathname n'autorise pas la consultation de
              son contenu. (Consultez aussi path_resolution(7).)

       EDQUOT Le quota utilisateur pour le système de fichiers a été dépassé
              (usage de blocs de disque ou d'inœuds).

       EEXIST pathname existe déjà. Cela inclut le cas où pathname est un lien
              symbolique, pouvant pointer nulle part.

       EFAULT nom_chemin pointe en dehors de l'espace d'adressage accessible.

       EINVAL mode demande la création d'autre chose qu'un fichier régulier,
              fichier spécial de périphérique, FIFO ou socket.

       ELOOP  Trop de liens symboliques ont été rencontrés en parcourant
              nom_chemin.

       ENAMETOOLONG
              nom_chemin est trop long.

       ENOENT Un des répertoires du chemin d'accès nom_chemin n'existe pas ou
              est un lien symbolique pointant nulle part.

       ENOMEM La mémoire disponible du noyau n'était pas suffisante.

       ENOSPC Le périphérique contenant pathname n'a pas assez de place pour le
              nouveau nœud.

       ENOTDIR
              Un élément, utilisé comme répertoire, du chemin d'accès nom_chemin
              n'est pas en fait un répertoire.

       EPERM  mode demande la création d'un nœud autre qu'un fichier régulier,
              une FIFO (tube nommé) ou une socket du domaine UNIX, alors que le
              processus appelant n'est pas privilégié (sous Linux : n'a pas la
              capacité CAP_MKNOD). Cette erreur se produit également si le
              système de fichiers contenant pathname ne supporte pas les nœuds
              du type demandé.

       EROFS  pathname est placé sur un système de fichiers en lecture seule.

       Les erreurs supplémentaires suivantes peuvent survenir pour mknodat() :

       EBADF  dirfd n'est pas un descripteur de fichier valable.

       ENOTDIR
              pathname est relatif et dirfd est un descripteur de fichier
              faisant référence à un fichier qui n'est pas un dossier.

VERSIONS
       mknodat() a été ajouté au noyau Linux dans sa version 2.6.16 ; la glibc
       le gère depuis la version 2.4.

CONFORMITÉ
       mknod() : SVr4, BSD 4.4, POSIX.1-2001 (mais voir plus loin),
       POSIX.1-2008.

       mknodat() : POSIX.1-2008.

NOTES
       POSIX.1-2001 dit : « Le seul usage portable de mknod() est réservé à la
       création de fichiers spéciaux FIFO. Si le mode n'est pas S_IFIFO ou si
       dev n'est pas 0, alors le comportement de mknod() est indéterminé ».
       Toutefois, aujourd'hui, on ne devrait jamais utiliser mknod() pour cela ;
       on devrait utiliser mkfifo(3), une fonction spécialement conçue pour
       cela.

       Sous Linux, mknod() ne peut pas être utilisé pour créer des répertoires.
       Il faut créer les répertoires avec mkdir(2).

       There are many infelicities in the protocol underlying NFS.  Some of
       these affect mknod()  and mknodat().

VOIR AUSSI
       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)

COLOPHON
       Cette page fait partie de la publication 5.08 du projet man-pages Linux.
       Une description du projet et des instructions pour signaler des anomalies
       et la dernière version de cette page, peuvent être trouvées à l'adresse
       https://www.kernel.org/doc/man-pages/.


TRADUCTION
       La traduction française de cette page de manuel a été créée par
       Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin
       <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>,
       François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe
       Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
       luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas
       Huriaux <thomas.huriaux@gmail.com>, Nicolas François
       <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>,
       Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier
       <barbier@debian.org>, David Prévot <david@tilapin.org>, Cédric Boutillier
       <cedric.boutillier@gmail.com> et Frédéric Hantrais <fhantrais@gmail.com>

       Cette traduction est une documentation libre ; veuillez vous reporter à
       la GNU General Public License version 3 concernant les conditions de
       copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel,
       veuillez envoyer un message à <debian-l10n-french@lists.debian.org>.



Linux                             13 août 2020                          MKNOD(2)