Provided by: manpages-fr_4.18.1-1_all bug

NOM

       inode – Informations sur les inœuds de fichier

DESCRIPTION

       Chaque  fichier  possède  un  inœud  contenant  des  métadonnées  à propos du fichier. Une
       application peut récupérer ces métadonnées en utilisant stat(2) (ou des appels semblables)
       qui renvoie une structure stat, ou statx(2) qui renvoie une structure statx.

       Voici  une liste des informations habituellement trouvées dans, ou associées à, l’inœud de
       fichier avec les noms des champs correspondants de la structure renvoyée  par  stat(2)  et
       statx(2) :

       Périphérique où l’inœud réside
              stat.st_dev ; statx.stx_dev_minor et statx.stx_dev_major

              Chaque  inœud (ainsi que le fichier associé) réside dans un système de fichiers qui
              est hébergé dans un périphérique. Ce périphérique est identifié par une combinaison
              de  son ID (identifiant) majeur (qui identifie la classe générique du périphérique)
              et un ID mineur (qui identifie une instance particulière de la classe générique).

       Numéro d’inœud
              stat.st_ino ; statx.stx_ino

              Chaque fichier du système de fichiers possède un numéro unique d’inœud. Les numéros
              d’inœud  sont  garantis  uniques  seulement  à  l’intérieur  du système de fichiers
              (c’est-à-dire que les mêmes numéros d’inœud peuvent être utilisés dans des systèmes
              de  fichiers  différents,  ce qui est la raison pour laquelle les liens physique ne
              traversent pas les limites des systèmes de fichiers). Ce champ contient  le  numéro
              d’inœud du fichier.

       Mode et type de fichier
              stat.st_mode ; statx.stx_mode

              Consultez les détails ci-dessous sur le mode et le type de fichier.

       Comptage des liens
              stat.st_nlink ; statx.stx_nlink

              Ce   champ   contient   le   nombre  de  liens  physiques  du  fichier.  Des  liens
              supplémentaires vers un fichier existant sont créés en utilisant link(2).

       ID utilisateur
              st_uid stat.st_uid ; statx.stx_uid

              Ce champ enregistre les  ID  utilisateur  du  propriétaire  du  fichier.  Pour  les
              fichiers  nouvellement  créés,  l’ID  utilisateur  est l’ID utilisateur effectif du
              processus créateur. L’ID utilisateur d’un fichier peut être  modifié  en  utilisant
              chown(2).

       ID groupe
              stat.st_gid ; statx.stx_gid

              L’inœud  enregistre  l’ID  du  propriétaire du groupe du fichier. Pour les fichiers
              nouvellement créés, l’ID groupe du fichier  est  soit  l’ID  groupe  du  répertoire
              parent ou l’ID groupe effectif du processus créateur, selon que le bit set-group-ID
              est établi sur le répertoire  parent  (voir  ci-dessous).  L’ID  groupe  peut  être
              modifié en utilisant chown(2).

       Périphérique représenté par cet inœud
              stat.st_rdev ; statx.stx_rdev_minor et statx.stx_rdev_major

              Si  ce  fichier (inœud) représente un périphérique, alors l’inœud enregistre les ID
              majeur et mineur de ce périphérique.

       Taille de fichier
              stat.st_size ; statx.stx_size

              Ce champ indique la taille du fichier (s'il s'agit d'un fichier ordinaire  ou  d'un
              lien  symbolique)  en octets. La taille d'un lien symbolique est la longueur du nom
              de chemin qu'il vise, sans l’octet NULL final.

       Taille de bloc préférée pour les E/S
              stat.st_blksize ; statx.stx_blksize

              Ce champ indique la taille de bloc « préférée » pour des entrées-sorties  efficaces
              de  système  de  fichiers. Des écritures par blocs plus petits peuvent entraîner un
              cycle lecture/modification/réécriture inefficace.

       Nombre de blocs alloués au fichier
              stat.st_blocks ; statx.stx_size

              Ce champ indique le nombre de blocs de 512 octets alloués au fichier. Cette  valeur
              peut être inférieure à st_size/512 si le fichier a des trous.

              La  norme POSIX.1 signale que l’unité pour un membre st_blocks de la structure stat
              n’est pas définie dans la norme. Dans beaucoup d’implémentations, c’est 512 octets.
              Dans quelques systèmes, une unité différente est utilisée, telle que 1024. De plus,
              l’unité peut être différente en fonction des systèmes de fichiers.

       Horodatage du dernier accès (atime)
              stat.st_atime ; statx.stx_atime

              C’est l’horodatage du dernier accès au fichier. Il est modifié  par  les  accès  au
              fichier,  par exemple, avec execve(2), mknod(2), pipe(2), utime(2) et read(2) (d'au
              moins un octet). D'autres interfaces, comme mmap(2), peuvent ou non mettre  à  jour
              l’horodatage atime.

              Certains  systèmes de fichiers autorisent le montage de telle manière que les accès
              à des fichiers ou  des  répertoires  ne  modifient  pas  l’horodatage  atime  (voir
              noatime,   nodiratime   et   relatime   de  mount(8)  ainsi  que  les  informations
              correspondantes dans mount(2)). De plus, l’horodatage atime n'est pas mis à jour si
              un fichier est ouvert avec l'indicateur O_NOATIME. Consultez open(2).

       Horodatage de création (birth) de fichier (btime)
              Non renvoyé dans la structure stat ; statx.stx_btime.

              C’est  l’horodatage  de  création  de fichier. Il est défini à la création et n’est
              plus modifié.

              L’horodatage btime n’était pas présent autrefois dans les systèmes  UNIX  et  n’est
              pas actuellement pris en charge dans la plupart des systèmes Linux.

       Horodatage de la dernière modification (mtime)
              stat.st_mtime ; statx.stx_mtime

              C’est  l’horodatage  de la dernière modification de fichier. Il est modifié par des
              changements sur le fichier,  par  exemple,  effectués  par  mknod(2),  truncate(2),
              utime(2)  et  write(2) (d'au moins un octet). D'autre part, l’horodatage mtime d'un
              répertoire est modifié lors de la création ou la suppression  de  fichiers  en  son
              sein.  L’horodatage  mtime  n'est  pas  mis  à  jour  lors  d’une  modification  de
              propriétaire, groupe, mode ou nombre de liens physiques.

       Horodatage de la dernière modification d’état (ctime)
              stat.st_ctime ; statx.stx_ctime

              C’est l’horodatage de la dernière modification d’état. Il est  modifié  lors  d'une
              écriture ou d’une modification des informations d’inœud (c’est-à-dire propriétaire,
              groupe, mode, nombre de liens physiques, etc.).

       Les champs d’horodatage indiquent le temps mesuré avec  comme  point  de  départ  l’Époque
       — 1970-01-01 00:00:00 +0000 UTC (consultez time(7)).

       Les horodatages en nanoseconde sont permis sur les systèmes de fichiers XFS, JFS, Btrfs et
       ext4 (depuis Linux 2.6.23). Les horodatages en nanoseconde ne  sont  pas  permis  sur  les
       systèmes  de fichiers ext2, ext3 et Reiserfs. Dans le but de renvoyer des horodatages avec
       une précision d'une nanoseconde, les champs d’horodatage dans les structures stat et statx
       sont  définis  sous  forme  de  structures  qui  incluent  une  composante en nanoseconde.
       Consultez stat(2) et statx(2) pour davantage d’informations. Sur les systèmes de  fichiers
       qui  ne  permettent  pas  les résolutions inférieures à la seconde, les champs nanoseconde
       dans les structures stat et statx sont renvoyés avec comme valeur zéro.

   Type et mode de fichier
       Le champ stat.st_mode (pour statx(2), le champ statx.stx_mode) contient le type et le mode
       de fichier.

       POSIX  rattache  les bits stat.st_mode correspondant au masque S_IFMT (voir ci-dessous) au
       type de fichier, les 12 bits correspondant au masque 07777 aux bits de mode de fichier  et
       les 9 bits les moins significatifs (0777) aux bits de permission de fichier.

       Les valeurs de masque suivantes sont définies pour le type de fichier :

           S_IFMT     0170000   masque de bits pour le champ de bits de type de fichier

           S_IFSOCK   0140000   socket
           S_IFLNK    0120000   lien symbolique.
           S_IFREG    0100000   fichier normal
           S_IFBLK    0060000   périphérique bloc
           S_IFDIR    0040000   répertoire
           S_IFCHR    0020000   périphérique caractère
           S_IFIFO    0010000   FIFO

       Ainsi, pour tester (par exemple) un fichier normal, il est possible d’écrire :

           stat(pathname, &sb);
           if ((sb.st_mode & S_IFMT) == S_IFREG) {
               /* Traiter les fichiers normaux */
           }

       Puisque  les  tests  de  la  forme précédente sont usuels, des macros supplémentaires sont
       définies par POSIX pour permettre d’écrire le test de type  de  fichier  dans  st_mode  de
       façon plus concise :

           S_ISREG(m)  est-ce un fichier ordinaire ?

           S_ISDIR(m)  un répertoire ?

           S_ISCHR(m)  un périphérique caractère ?

           S_ISBLK(m)  un périphérique bloc ?

           S_ISFIFO(m) un FIFO (tube nommé) ?

           S_ISLNK(m)  un lien symbolique ? (Pas dans POSIX.1-1996).

           S_ISSOCK(m) un socket ? (Pas dans POSIX.1-1996).

       Le morceau de code précédent pourrait donc être réécrit comme ceci :

           stat(pathname, &sb);
           if (S_ISREG(sb.st_mode)) {
               /* Traiter les fichiers normaux */
           }

       Les  définitions  de  la  plupart  des  macros de test de type de fichier précédentes sont
       fournies si une des macros de test de fonctionnalité suivantes est  définie :  _BSD_SOURCE
       (dans  glibc 2.19  et  versions  précédentes),  _SVID_SOURCE  (dans glibc 2.19 et versions
       précédentes) ou _DEFAULT_SOURCE (dans glibc 2.20  et  versions  suivantes).  De  plus  les
       définitions  de  toutes les macros précédentes à part S_IFSOCK et S_ISSOCK() sont fournies
       si _XOPEN_SOURCE est définie.

       La définition de S_IFSOCK peut aussi être exposée soit en définissant  _XOPEN_SOURCE  avec
       une  valeur  de  500  ou  plus,  soit  (depuis glibc 2.24) en définissant _XOPEN_SOURCE et
       _XOPEN_SOURCE_EXTENDED.

       La définition de S_ISSOCK() est exposée si  une  des  macros  de  test  de  fonctionnalité
       suivantes   est   définie :   _BSD_SOURCE   (dans  glibc 2.19  et  versions  précédentes),
       _DEFAULT_SOURCE (dans glibc 2.20 et versions suivantes), _XOPEN_SOURCE avec une valeur  de
       500 ou plus, _POSIX_C_SOURCE avec une valeur de 200112L ou plus, ou (depuis glibc 2.24) en
       définissant _XOPEN_SOURCE et _XOPEN_SOURCE_EXTENDED.

       Les valeurs de masque suivantes sont définies pour le composant  de  mode  de  fichier  du
       champ st_mode :

           S_ISUID     04000   bit set-user-ID (voir execve(2))
           S_ISGID     02000   bit set-group-ID (voir ci-dessous)
           S_ISVTX     01000   sticky bit (voir ci-dessous)

           S_IRWXU     00700   droits de lecture, écriture et exécution pour le propriétaire
           S_IRUSR     00400   droit de lecture pour le propriétaire
           S_IWUSR     00200   droit d'écriture pour le propriétaire
           S_IXUSR     00100   droit d'exécution pour le propriétaire

           S_IRWXG     00070   droits de lecture, écriture et exécution pour le groupe
           S_IRGRP     00040   droit de lecture pour le groupe
           S_IWGRP     00020   droit d'écriture pour le groupe
           S_IXGRP     00010   droit d'exécution pour le groupe

           S_IRWXO     00007   droits de lecture, écriture et exécution pour les autres (pas dans
                               le groupe)
           S_IROTH     00004   droit de lecture pour les autres
           S_IWOTH     00002   droit d'écriture pour les autres
           S_IXOTH     00001   droit d'exécution pour les autres

       Le bit set-group-ID (S_ISGID) a plusieurs utilisations particulières. Pour un  répertoire,
       il  indique  que  la  sémantique BSD doit être appliquée en son sein, c'est-à-dire que les
       fichiers qui y sont créés héritent leur ID groupe du répertoire et non pas de l’ID  groupe
       effectif  du  processus  créateur,  et  les sous-répertoires auront automatiquement le bit
       S_ISGID actif. Pour les fichiers exécutables, le bit set-group-ID  fait  que  l’ID  groupe
       effectif d’un processus qui exécute le fichier change comme décrit dans execve(2). Pour un
       fichier qui n’a pas d'autorisation d'exécution pour le groupe (S_IXGRP non actif), ce  bit
       indique qu'un verrouillage strict est en vigueur sur ce fichier.

       Le bit « sticky » (S_ISVTX) sur un répertoire indique que les fichiers qui s'y trouvent ne
       peuvent être renommés ou effacés  que  par  leur  propriétaire,  par  le  propriétaire  du
       répertoire ou par un processus privilégié.

STANDARDS

       Si  vous  avez  besoin  de  connaître  la  définition  des  types blkcnt_t ou blksize_t de
       <sys/stat.h>, alors définissez _XOPEN_SOURCE avec une valeur supérieure  ou  égale  à  500
       (avant d'inclure tout en‐tête).

       POSIX.1-1990  ne décrivait pas les constantes S_IFMT, S_IFSOCK, S_IFLNK, S_IFREG, S_IFBLK,
       S_IFDIR, S_IFCHR, S_IFIFO, S_ISVTX, mais réclame d'utiliser les macros S_ISDIR(), etc. Les
       constantes S_IF* sont présentes dans POSIX.1-2011 et les versions suivantes.

       Les  macros  S_ISLNK() et S_ISSOCK() ne sont pas présentes dans POSIX.1-1996, mais le sont
       dans POSIX.1-2001. La première vient de SVID 4, la seconde de SUSv2.

       UNIX V7 (et les systèmes suivants) propose  S_IREAD,  S_IWRITE,  etS_IEXEC,  là  où  POSIX
       préfère leurs synonymes S_IRUSR, S_IWUSR et S_IXUSR.

NOTES

       For  pseudofiles  that  are  autogenerated  by  the  kernel,  the file size (stat.st_size;
       statx.stx_size)  reported by the kernel is not accurate.  For  example,  the  value  0  is
       returned for many files under the /proc directory, while various files under /sys report a
       size of 4096 bytes, even though the file content is smaller. For such  files,  one  should
       simply try to read as many bytes as possible (and append '\0' to the returned buffer if it
       is to be interpreted as a string).

VOIR AUSSI

       stat(1), stat(2), statx(2), symlink(7)

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> et Jean-Paul Guillonneau
       <guillonneau.jeanpaul@free.fr>

       Cette traduction est une documentation libre ; veuillez vous reporter  à  la  GNU  General
       Public   License   version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  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⟩.