inode?

Juste commencé à lire un peu sur le système de files Linux. Dans plusieurs endroits, j'ai trouvé des citations comme celle-ci:

Les directorys Unix sont des lists de structures d'association contenant chacune un nom de file et un numéro d'inode.

Je m'attendais donc à découvrir que chaque directory contiendrait les noms des files sous lui, chaque file étant mappé à un inode. Mais quand je vim directory_name dans ubuntu, je reçois quelque chose comme ceci:

 " ============================================================================ " Netrw Directory Listing (netrw v156) " /Users/user/workspace/folder " Sorted by name " Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$ " Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special " ============================================================================== ../ ./ folder1/ folder2/ file1 file2

Je m'attendais à voir un numéro d'inode à côté de chaque nom de file, pourquoi n'est-ce pas le cas?

Un directory est, sémantiquement parlant, un mappage du nom de file à l'inode. C'est ainsi que l'abstraction de l'arborescence des directorys est conçue, correspondant à l'interface entre les applications et les filesystems. Les applications peuvent désigner des files par nom et énumérer la list des files dans un directory, et chaque file a un désignateur unique appelé "inode".

L'implémentation de cette sémantique dépend du type de système de files. C'est à chaque système de files comment le directory est encodé. Dans la plupart des filesystems Unix, un directory est un mappage entre les noms de files et les numéros d'inode, et une table distincte mappe les numéros d'inode en données inodes. (Les données inode contiennent des métadonnées de file telles que les permissions et les horodatages, l'location du contenu du file, etc.) Le mappage peut être une list, une table de hachage, une arborescence …

Vous ne pouvez pas voir ce mappage avec Vim. Vim n'affiche pas la zone de stockage qui représente le directory. Linux, comme beaucoup d'autres systèmes Unix modernes, n'autorise pas les applications à voir directement la représentation du directory. Les directorys agissent comme des files ordinaires en ce qui concerne leur input dans le directory et leurs métadonnées, mais pas quand il s'agit de leur contenu. Applications lues à partir d'un file ordinaire avec des appels système tels que open , read , write , close ; pour les directorys, il y a d'autres appels système: opendir , readdir , closedir et la modification d'un directory se fait en créant, en déplaçant et en supprimant des files. Une application comme cat utilise open , read , close de lire le contenu d'un file; une application comme ls utilise opendir , readdir , closedir pour lire le contenu d'un directory. Vim fonctionne normalement comme un cat pour lire le contenu d'un file, mais si vous lui requestz d'ouvrir un directory, il fonctionne comme ls et imprime datatables d'une manière bien formatée.

Si vous voulez voir à quoi ressemble un directory sous le capot, vous pouvez utiliser un outil tel que debugfs pour ext2 / ext3 / ext4. Assurez-vous de ne rien modifier! Un outil comme debugfs contourne le système de files et peut le détruire complètement. Le file debugfs ext2 / ext3 / ext4 est sûr car il est en mode lecture seule, sauf si vous autorisez explicitement l'écriture via une option de command line.

 # debugfs /dev/root debugfs 1.42.12 (29-Aug-2014) debugfs: dump / /tmp/root.bin debugfs: quit # od -t x1 /tmp/root.bin

Vous verrez les noms des inputs du directory dans / parmi un tas d'autres caractères, certains non imprimables. Pour en comprendre le sens, vous devez connaître les détails du format du système de files.

Cette citation parle de la façon dont (logiquement, les structures actuelles sont souvent très différentes de nos jours), les filesystems Unix fonctionnent. Et vous pouvez voir les numéros d'inode avec, par exemple, le drapeau -i à ls :

 $ ls -li total 8 532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a 532540 -rw-r--r-- 1 anthony anthony 70 Apr 25 12:07 b

Ce nombre à gauche est l'inode. Et si je cours ln bc (création d'un lien), alors:

 $ ls -li total 12 532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a 532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 b 532540 -rw-r--r-- 2 anthony anthony 70 Apr 25 12:07 c

Les permissions et la taille font partie de l'inode, pas le directory. Assez facile de voir par ce qui se passe après chmod 0600 c :

 $ ls -li total 12 532028 -rw-r--r-- 1 anthony anthony 115 Apr 25 12:07 a 532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 b 532540 -rw------- 2 anthony anthony 70 Apr 25 12:07 c

les deux b et c changé, car ils partagent le même inode.

Cependant, le kernel expose seulement le système de files à l'espace user sur une API bien définie (à l'exception des périphériques bruts comme /dev/sda1 ). Il permet à l'espace user d'accéder à un set de syscalls pour créer et supprimer des liens, modifier les permissions, lire et écrire des files, renommer, etc. Il n'expose pas les data structures de système de files sous-jacentes à l'espace user. Pour de nombreuses raisons: cela permet aux filesystems en réseau d'imposer les permissions et de conserver les data structures du système de files, ce qui signifie que vous pouvez utiliser différents filesystems (sans structure de données) sans changer d'espace user.

Donc, en gros, vim dir vous montre juste une list de directorys – plus ou less comme ls fait. Cela se fait via un module vim appelé Netrw, comme il le dit en haut (essayez :help netrw in vim). Vous ne pouvez pas modifier les data structures du système de files sous-jacent.

Je soupçonne que vous lisez peut-être un très, très vieux exposé sur le fonctionnement du système de files Unix. Ce que vous décrivez aurait été vrai à la fin des années 1970, mais il n'est plus vrai dans aucun système de files moderne.

Sur de nombreuses plates-forms modernes, plusieurs filesystems sont utilisés en commun, et chacun d'entre eux cache ses internes de l'espace user. Vous pouvez découvrir à quoi ils ressemblent et jouer avec eux, mais si vous ne voulez pas vous spécialiser dans la design de filesystems, il vaut peut-être mieux faire confiance à l'auteur du livre pour vous donner une idée de base du design. trop de détails (dont certains seront obsolètes au moment où vous en avez besoin de toute façon).