lundi 13 janvier 2014

Qu'est ce que st_nlink exactement ?

Le problème est de déterminer si l'interprétation HFS+ (le système de fichier natif de MacOSX) est conforme au standard POSIX. En général, on considère l'interprétation conduisant à déduire du nombre de liens associés à un inœud de type répertoire, le nombre de sous-répertoires qu'il possède (en supposant d'ailleurs qu'aucun hard-link n'est autorisé autrement que via mkdir()).

Les gnous en disent :
The number of hard links to the file. This count keeps track of how many directories have entries for this file. If the count is ever decremented to zero, then the file itself is discarded as soon as no process still holds it open. Symbolic links are not counted in the total.

Le standard POSIX 1003.1-1988 affirme :
§5.6.1 The value of the member st_nlink shall be set to the number of links to the file. 
§2.3 link. See directory entry. 
§2.3 directory entry (or link). An object that associates a filename with a file. Several directory entries can associate names with the same file.
Creusons un peu plus loin dans POSIX :
§2.3 file. An object that can be written to, or read from, or both. A file has certain attributes, including access permissions and type. File types include regular file, character special file, block special file, FIFO special file, and directory. Other types of files may be defined by the implementation.
§2.3 filename. A name consisting of 1 to [NAME_MAX] bytes used to name a file. The characters composing the name may be selected from the set of all character values excluding the slash character and the null character. The filenames dot and dot-dot have a special meaning; see pathname resolution §2.4. A filename is sometimes referred to as a pathname component.
Ce qui est remarquable (à mes yeux) est que dans ces définitions aucune référence explicite n'est faite au contenant des directory entries. On suppose habituellement que les directory entries sont nécessairement contenues dans des fichiers de type répertoire, mais ce n'est nullement précisé. Ce qui est précisé c'est le contenu d'un répertoire :
§2.3 directory. A file that contains directory entries. No two directory entries in the same directory shall have the same name.
Par conséquent, il n'est pas (à mes yeux) interdit d'imaginer que st_nlink pour les répertoires se comporte comme dans MacOSX, c'est-à-dire correspond au nombre d'entrées dans le répertoire. À tout fichier HFS+ correspond un lien vers le répertoire qui le contient.

Attention! Je ne prétends pas ici que HFS+ est POSIX-compliant! D'ailleurs qu'est-ce que cela signifierait ? Les filesystems ne sont pas en eux-même conformes à une norme sémantique, fusse t-elle POSIX. Les systèmes de fichiers ne sont que des structures de données, il n'y a qu'une couche logicielle qui puisse imposer une sémantique. J'affirme donc que la sémantique POSIX est respectée par le couple OSX/HFS+, autrement dit que via OSX la sémantique est respectée. D'ailleurs OSX n'est autre que Darwin, une personnalité FreeBSD de Mach. Je l'affirme a contrario de nombreux articles Internet sur le sujet.

Question subsidiaire : existe t-il dans une distribution Unix classique (je n'ai pas de définition autre que le sens commun) un outil standard qui utilise la valeur du champ st_nlink pour faire quelque chose d'intéressant ? J'exclue d'office un outil type fsck dont le rôle est justement d'examiner la structure du filesystem à des fins de réparation par exemple...

DjiBee

2 commentaires:

  1. Pfiouh. Je ne connais pas le fonctionnement de st_nlink sur OSX/HFS+ , mais une petite recherche sur GETA (Google Est Ton Ami) semble indiquer qu'il y a d'autres systèmes de fichiers où le nombre de liens n'est pas géré selon l'habitude.

    Apparemment, AFS est de ceus là. Btrfs mettrait (conditionnel) ce compteur à 1, et ReiserFS le mettrait à1 quand le nombre de liens excèdent la valeur stockable... Faudrait juste vérifier ces infos glanées sur le Web. Et bien sur les bon vieux systèmes de fichiers comme FAT / FAT32 ne supportent pas ce genre de chose.

    Il y a aussi visiblement des scripts (notamment Python - youhou Yann) qui font des hypothèses (optimisations?) sur la valeur et qui du coup se cassent les dents sut Btrfs.

    Ça serait (? conditionnel, suivant la version ?) utilisé pour supporter des appels comme inotify... Cf; http://lwn.net/Articles/432427/

    RépondreSupprimer
  2. Intéressantes tes remarques. Pour inotify, je pense que l'utilisation de cette donnée n'est qu'une optimisation car il n'y a à mes yeux aucune raison qu'un mécanisme type inotify ait besoin de la valeur... MacOSX possède son propre système de notification sur le FS, c'est d'ailleurs trop méconnu car il est très agréable d'attacher des tâches sur des répertoires par exemple.

    RépondreSupprimer