C'est en fait assez simple, du moins si vous n'avez pas besoin des détails de mise en œuvre.
Tout d'abord, sous Linux, tous les systèmes de fichiers (ext2, ext3, btrfs, reiserfs, tmpfs, zfs, ...) sont implémentés dans le noyau. Certains peuvent décharger le travail vers le code de l'utilisateur par le biais de FUSE, et d'autres ne sont disponibles que sous la forme d'un module du noyau ( ZFS natif est un exemple notable de cette dernière en raison des restrictions de licence), mais dans tous les cas, il reste un composant noyau. Il s'agit d'une base importante.
Lorsqu'un programme veut lire un fichier, il lance divers appels à la bibliothèque système qui aboutissent finalement dans le noyau sous la forme d'un fichier de type open()
, read()
, close()
(éventuellement avec seek()
pour faire bonne mesure). Le noyau prend le chemin d'accès et le nom de fichier fournis et, par l'intermédiaire du système de fichiers et de la couche E/S du périphérique, les traduit en requêtes de lecture physique (et dans de nombreux cas, en requêtes d'écriture - pensez par exemple aux mises à jour atime) vers un stockage sous-jacent.
Cependant, il n'a pas à traduire ces requêtes spécifiquement pour physique, persistant stockage . Le contrat du noyau est que l'émission d'un ensemble particulier d'appels système va fournir le contenu du fichier en question . L'endroit exact où se trouve le "fichier" dans notre monde physique est secondaire.
Sur /proc
est généralement monté ce que l'on appelle procfs
. Il s'agit d'un type de système de fichiers spécial, mais puisqu'il s'agit d'un système de fichiers, il n'est pas vraiment différent d'un système de fichiers de type . ext3
système de fichiers monté quelque part. La requête est donc transmise au code du pilote du système de fichiers procfs, qui connaît tous ces fichiers et répertoires et renvoie des éléments d'information particuliers à partir des structures de données du noyau .
Dans ce cas, la "couche de stockage" est constituée par les structures de données du noyau. procfs
fournit une interface propre et pratique pour y accéder. Gardez à l'esprit que le montage de procfs à /proc
est simplement une convention ; vous pourriez tout aussi bien le monter ailleurs. En fait, cela est parfois fait, par exemple dans les jails chroot lorsque le processus qui s'y exécute a besoin d'accéder à /proc pour une raison quelconque.
Cela fonctionne de la même manière si vous écrivez une valeur dans un fichier ; au niveau du noyau, cela se traduit par une série de open()
, seek()
, write()
, close()
qui sont à nouveau passés au pilote du système de fichiers ; à nouveau, dans ce cas particulier, le code procfs.
La raison particulière pour laquelle vous voyez file
en retournant sur empty
est que beaucoup de fichiers exposés par procfs sont exposés avec une taille de 0 octet. La taille de 0 octet est probablement une optimisation du côté du noyau (beaucoup de fichiers dans /proc sont dynamiques et peuvent facilement varier en longueur, peut-être même d'une lecture à l'autre, et calculer la longueur de chaque fichier à chaque lecture de répertoire serait potentiellement très coûteux). D'après les commentaires de cette réponse, que vous pouvez vérifier sur votre propre système en utilisant strace ou un outil similaire, file
publie d'abord un stat()
pour détecter tout fichier spécial, et en profite pour, si la taille du fichier est égale à 0, abandonner et signaler que le fichier est vide.
Ce comportement est en fait documenté et peut être remplacée en spécifiant -s
o --special-files
sur le file
l'invocation, bien que, comme indiqué dans la page du manuel, cela puisse avoir des effets secondaires. La citation ci-dessous est tirée de la page de manuel BSD file 5.11, datée du 17 octobre 2011.
Normalement, file tente seulement de lire et de déterminer le type de fichiers d'arguments que stat(2) rapporte être des fichiers ordinaires. Cela évite les problèmes, car la lecture de fichiers spéciaux peut avoir des conséquences particulières. En spécifiant l'option -s
permet au fichier de lire également les fichiers d'arguments qui sont des fichiers spéciaux de blocs ou de caractères. Ceci est utile pour déterminer les types de système de fichiers des données dans les partitions de disque brutes, qui sont des fichiers spéciaux de bloc. Cette option permet également au fichier de ne pas tenir compte de la taille du fichier telle que rapportée par stat(2). car sur certains systèmes, il rapporte une taille nulle pour les partitions de disque brut.