.\" -*- coding: UTF-8 -*- '\" t .\" Copyright (c) 2017 Michael Kerrisk .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH inode 7 "30 juillet 2023" "Pages du manuel de Linux 6.05.01" .SH NOM inode – Informations sur les inœuds de fichier .SH 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 \fBstat\fP(2) (ou des appels semblables) qui renvoie une structure \fIstat\fP, ou \fBstatx\fP(2) qui renvoie une structure \fIstatx\fP. .PP 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 \fBstat\fP(2) et \fBstatx\fP(2)\ : .TP Périphérique où l’inœud réside \fIstat.st_dev\fP\ ; \fIstatx.stx_dev_minor\fP et \fIstatx.stx_dev_major\fP .IP 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). .TP Numéro d’inœud \fIstat.st_ino\fP\ ; \fIstatx.stx_ino\fP .IP 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. .TP Mode et type de fichier \fIstat.st_mode\fP\ ; \fIstatx.stx_mode\fP .IP Consultez les détails ci\-dessous sur le mode et le type de fichier. .TP Comptage des liens \fIstat.st_nlink\fP\ ; \fIstatx.stx_nlink\fP .IP Ce champ contient le nombre de liens physiques du fichier. Des liens supplémentaires vers un fichier existant sont créés en utilisant \fBlink\fP(2). .TP ID utilisateur \fIst_uid\fP \fIstat.st_uid\fP\ ; \fIstatx.stx_uid\fP .IP 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 \fBchown\fP(2). .TP ID groupe \fIstat.st_gid\fP\ ; \fIstatx.stx_gid\fP .IP 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 \fBchown\fP(2). .TP Périphérique représenté par cet inœud \fIstat.st_rdev\fP\ ; \fIstatx.stx_rdev_minor\fP et \fIstatx.stx_rdev_major\fP .IP 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. .TP Taille de fichier \fIstat.st_size\fP\ ; \fIstatx.stx_size\fP .IP 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. .TP Taille de bloc préférée pour les E/S \fIstat.st_blksize\fP\ ; \fIstatx.stx_blksize\fP .IP 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. .TP Nombre de blocs alloués au fichier \fIstat.st_blocks\fP\ ; \fIstatx.stx_size\fP .IP Ce champ indique le nombre de blocs de 512\ octets alloués au fichier. Cette valeur peut être inférieure à \fIst_size\fP/512 si le fichier a des trous. .IP .\" Rationale for sys/stat.h in POSIX.1-2008 La norme POSIX.1 signale que l’unité pour un membre \fIst_blocks\fP de la structure \fIstat\fP 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. .TP Horodatage du dernier accès (atime) \fIstat.st_atime\fP\ ; \fIstatx.stx_atime\fP .IP C’est l’horodatage du dernier accès au fichier. Il est modifié par les accès au fichier, par exemple, avec \fBexecve\fP(2), \fBmknod\fP(2), \fBpipe\fP(2), \fButime\fP(2) et \fBread\fP(2) (d'au moins un octet). D'autres interfaces, comme \fBmmap\fP(2), peuvent ou non mettre à jour l’horodatage atime. .IP 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 \fInoatime\fP, \fInodiratime\fP et \fIrelatime\fP de \fBmount\fP(8) ainsi que les informations correspondantes dans \fBmount\fP(2)). De plus, l’horodatage atime n'est pas mis à jour si un fichier est ouvert avec l'indicateur \fBO_NOATIME\fP. Consultez \fBopen\fP(2). .TP Horodatage de création (birth) de fichier (btime) Non renvoyé dans la structure \fIstat\fP\ ; \fIstatx.stx_btime\fP. .IP C’est l’horodatage de création de fichier. Il est défini à la création et n’est plus modifié. .IP .\" FIXME Is it supported on ext4 and XFS? 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. .TP Horodatage de la dernière modification (mtime) \fIstat.st_mtime\fP\ ; \fIstatx.stx_mtime\fP .IP 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 \fBmknod\fP(2), \fBtruncate\fP(2), \fButime\fP(2) et \fBwrite\fP(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 \fIpas\fP mis à jour lors d’une modification de propriétaire, groupe, mode ou nombre de liens physiques. .TP Horodatage de la dernière modification d’état (ctime) \fIstat.st_ctime\fP\ ; \fIstatx.stx_ctime\fP .IP 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.). .PP Les champs d’horodatage indiquent le temps mesuré avec comme point de départ l’\fIÉpoque\fP —\ 1970\-01\-01\ 00:00:00\ +0000\ UTC (consultez \fBtime\fP(7)). .PP .\" commit ef7f38359ea8b3e9c7f2cae9a4d4935f55ca9e80 .\" 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 \fIstat\fP et \fIstatx\fP sont définis sous forme de structures qui incluent une composante en nanoseconde. Consultez \fBstat\fP(2) et \fBstatx\fP(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 \fIstat\fP et \fIstatx\fP sont renvoyés avec comme valeur zéro. .SS "Type et mode de fichier" Le champ \fIstat.st_mode\fP (pour \fBstatx\fP(2), le champ \fIstatx.stx_mode\fP) contient le type et le mode de fichier. .PP POSIX rattache les bits \fIstat.st_mode\fP correspondant au masque \fBS_IFMT\fP (voir ci\-dessous) au \fItype de fichier\fP, les 12\ bits correspondant au masque 07777 aux \fIbits de mode de fichier\fP et les 9\ bits les moins significatifs (0777) aux \fIbits de permission de fichier\fP. .PP Les valeurs de masque suivantes sont définies pour le type de fichier\ : .in +4n .TS lB l l. 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 .TE .in .PP Ainsi, pour tester (par exemple) un fichier normal, il est possible d’écrire\ : .PP .in +4n .EX stat(pathname, &sb); if ((sb.st_mode & S_IFMT) == S_IFREG) { /* Traiter les fichiers normaux */ } .EE .in .PP 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 \fIst_mode\fP de façon plus concise\ : .RS 4 .TP 1.2i \fBS_ISREG\fP(m) est\-ce un fichier ordinaire\ ? .TP \fBS_ISDIR\fP(m) un répertoire\ ? .TP \fBS_ISCHR\fP(m) un périphérique caractère\ ? .TP \fBS_ISBLK\fP(m) un périphérique bloc\ ? .TP \fBS_ISFIFO\fP(m) un FIFO (tube nommé)\ ? .TP \fBS_ISLNK\fP(m) un lien symbolique\ ? (Pas dans POSIX.1\-1996). .TP \fBS_ISSOCK\fP(m) un socket\ ? (Pas dans POSIX.1\-1996). .RE .PP Le morceau de code précédent pourrait donc être réécrit comme ceci\ : .PP .in +4n .EX stat(pathname, &sb); if (S_ISREG(sb.st_mode)) { /* Traiter les fichiers normaux */ } .EE .in .PP 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\ : \fB_BSD_SOURCE\fP (dans glibc\ 2.19 et versions précédentes), \fB_SVID_SOURCE\fP (dans glibc\ 2.19 et versions précédentes) ou \fB_DEFAULT_SOURCE\fP (dans glibc\ 2.20 et versions suivantes). De plus les définitions de toutes les macros précédentes à part \fBS_IFSOCK\fP et \fBS_ISSOCK\fP() sont fournies si \fB_XOPEN_SOURCE\fP est définie. .PP La définition de \fBS_IFSOCK\fP peut aussi être exposée soit en définissant \fB_XOPEN_SOURCE\fP avec une valeur de 500 ou plus, soit (depuis glibc\ 2.24) en définissant \fB_XOPEN_SOURCE\fP et \fB_XOPEN_SOURCE_EXTENDED\fP. .PP La définition de \fBS_ISSOCK\fP() est exposée si une des macros de test de fonctionnalité suivantes est définie\ : \fB_BSD_SOURCE\fP (dans glibc\ 2.19 et versions précédentes), \fB_DEFAULT_SOURCE\fP (dans glibc\ 2.20 et versions suivantes), \fB_XOPEN_SOURCE\fP avec une valeur de 500 ou plus, \fB_POSIX_C_SOURCE\fP avec une valeur de 200112L ou plus, ou (depuis glibc\ 2.24) en définissant \fB_XOPEN_SOURCE\fP et \fB_XOPEN_SOURCE_EXTENDED\fP. .PP Les valeurs de masque suivantes sont définies pour le composant de mode de fichier du champ \fIst_mode\fP\ : .in +4n .TS lB l lx. S_ISUID 04000 T{ bit set\-user\-ID (voir \fBexecve\fP(2)) T} S_ISGID 02000 T{ bit set\-group\-ID (voir ci\-dessous) T} S_ISVTX 01000 T{ sticky bit (voir ci\-dessous) T} S_IRWXU 00700 T{ droits de lecture, écriture et exécution pour le propriétaire T} S_IRUSR 00400 T{ droit de lecture pour le propriétaire T} S_IWUSR 00200 T{ droit d'écriture pour le propriétaire T} S_IXUSR 00100 T{ droit d'exécution pour le propriétaire T} S_IRWXG 00070 T{ droits de lecture, écriture et exécution pour le groupe T} S_IRGRP 00040 T{ droit de lecture pour le groupe T} S_IWGRP 00020 T{ droit d'écriture pour le groupe T} S_IXGRP 00010 T{ droit d'exécution pour le groupe T} S_IRWXO 00007 T{ droits de lecture, écriture et exécution pour les autres (pas dans le groupe) T} S_IROTH 00004 T{ droit de lecture pour les autres T} S_IWOTH 00002 T{ droit d'écriture pour les autres T} S_IXOTH 00001 T{ droit d'exécution pour les autres T} .TE .in .PP Le bit set\-group\-ID (\fBS_ISGID\fP) 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 \fBS_ISGID\fP 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 \fBexecve\fP(2). Pour un fichier qui n’a pas d'autorisation d'exécution pour le groupe (\fBS_IXGRP\fP non actif), ce bit indique qu'un verrouillage strict est en vigueur sur ce fichier. .PP Le bit «\ sticky\ » (\fBS_ISVTX\fP) 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é. .SH STANDARDS POSIX.1\-2008. .SH HISTORIQUE POSIX.1\-2001. .PP POSIX.1\-1990 ne décrivait pas les constantes \fBS_IFMT\fP, \fBS_IFSOCK\fP, \fBS_IFLNK\fP, \fBS_IFREG\fP, \fBS_IFBLK\fP, \fBS_IFDIR\fP, \fBS_IFCHR\fP, \fBS_IFIFO\fP, \fBS_ISVTX\fP, mais réclame d'utiliser les macros \fBS_ISDIR\fP(),\ etc. .PP Les macros \fBS_ISLNK\fP() et \fBS_ISSOCK\fP() ne sont pas présentes dans POSIX.1\-1996\ ; la première vient de SVID\ 4, la seconde de SUSv2. .PP UNIX\ V7 (et les systèmes suivants) propose \fBS_IREAD\fP, \fBS_IWRITE\fP, et\fBS_IEXEC\fP, là où POSIX préfère leurs synonymes \fBS_IRUSR\fP, \fBS_IWUSR\fP et \fBS_IXUSR\fP. .SH NOTES Pour les pseudo\-fichiers autogénérés par le noyau, la taille de fichier (\fIstat.st_size\fP, \fIstatx.stx_size\fP) 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 \fI/proc\fP, tandis que divers fichiers dans \fI/sys\fP 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 «\ \e0\ » au tampon renvoyé s’il est interprété comme une chaîne). .SH "VOIR AUSSI" \fBstat\fP(1), \fBstat\fP(2), \fBstatx\fP(2), \fBsymlink\fP(7) .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot et Jean-Paul Guillonneau . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .