Provided by: manpages-fr-dev_3.65d1p1-1_all bug

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   (consultez
   feature_test_macros(7)) :

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


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.

       L'argument mode définit à la fois les permissions d'utilisation, et  le  type  de  nœud  à
       créer. C'est une combinaison par OU binaire « | » entre l'un des types de nœuds ci‐dessous
       et les permissions d'accès pour le nouveau nœud.

       Les permissions sont modifiées par le umask du processus : les  permissions  effectivement
       écrites sont (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()
       L'appel  système  mknodat()  agit  exactement  de  la même façon que l'appel mknod(2), aux
       différences suivantes près.

       Si le chemin donné dans pathname est relatif, il est interprété par rapport au  répertoire
       référencé  par  le  descripteur  de  fichier  dirfd,  plutôt que par rapport au répertoire
       courant, comme dans mknod(2).

       Si pathname est un chemin relatif, et si dirfd est la valeur spéciale  AT_FDCWD,  pathname
       est  interprété  comme  étant  relatif  au répertoire courant du processus appelant, comme
       mknod(2).

       Si pathname est un chemin absolu, 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 pathname 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 pathname.

       ENAMETOOLONG
              pathname est trop long.

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

       ENOMEM Pas assez de mémoire pour le noyau.

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

       ENOTDIR
              Un élément du chemin d'accès pathname n'est pas 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 le descripteur de fichier dirfd est associé à un fichier,
              pas à un répertoire.


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).

       Il y a de nombreux problèmes avec le protocole sous‐jacent à  NFS,  certains  d'entre  eux
       pouvant affecter mknod() et mknodat(2).


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


COLOPHON
       Cette page fait partie de la publication 3.65 du projet man-pages Linux.  Une  description
       du  projet  et  des  instructions  pour  signaler  des  anomalies  peuvent être trouvées à
       l'adresse http://www.kernel.org/doc/man-pages/.


TRADUCTION
       Depuis   2010,   cette   traduction   est   maintenue   à   l'aide   de    l'outil    po4a
       <http://po4a.alioth.debian.org/>  par l'équipe de traduction francophone au sein du projet
       perkamon <http://perkamon.alioth.debian.org/>.

       Christophe   Blaess   <http://www.blaess.fr/christophe/>   (1996-2003),    Alain    Portal
       <http://manpagesfr.free.fr/>  (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de
       traduction de Debian (2006-2009).

       Veuillez     signaler     toute     erreur     de     traduction     en     écrivant     à
       <debian-l10n-french@lists.debian.org>   ou   par   un  rapport  de  bogue  sur  le  paquet
       manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de  ce  document  en  utilisant  la
       commande « man -L C <section> <page_de_man> ».