Provided by: manpages-fr_4.23.1-1_all 
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
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_blocks
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
POSIX.1-2008.
HISTORIQUE
POSIX.1-2001.
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 macros S_ISLNK() et S_ISSOCK() ne sont pas présentes dans POSIX.1-1996 ; 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
Pour les pseudo-fichiers autogénérés par le noyau, la taille de fichier (stat.st_size,
statx.stx_size) renvoyée par le noyau n’est pas précise. Par exemple, une valeur de zéro
est renvoyée pour de nombreux fichiers du répertoire /proc, tandis que divers fichiers
dans /sys renvoient une taille de 4096 octets, même si le contenu du fichier est plus
petit. Pour de tels fichiers, une lecture d'autant d’octets que possible devrait être
tentée (et ajouter « \0 » au tampon renvoyé s’il est interprété comme une chaîne).
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⟩.