Confusion sur les métadonnées | Fourches nommées | Attributs étendus | Fourchettes de ressources -- HFS+

Je ne suis pas un expert en la matière, mais j'ai lu un peu pour essayer de comprendre ce qui se passe.

Je dirais "La confusion vient du fait que :

• la relation entre ces concepts est complexe et
• a changé au fil du temps et
• Apple a implémenté à la fois les API au niveau du programme et des outils comme ls ou cp de manière à cacher de nombreuses différences entre les concepts."

AIUI, le fichier catalogue HFS+ contient des enregistrements de fichiers catalogue (entre autres choses). L'enregistrement du fichier de catalogue contient les informations habituelles sur le fichier, telles que la date de création, la date d'accès, etc. L'enregistrement du fichier de catalogue contient également deux structures qui donnent des informations sur l'emplacement et la taille de la fourche de données et de la fourche de ressources.

AIUI, HFS+ possède également (copié de Wikipedia HFS+) un "fichier d'attributs [qui] est un nouveau B-tree dans HFS Plus qui n'a pas de structure correspondante dans HFS. Le fichier d'attributs peut stocker trois types différents d'enregistrements de 4 Ko : Les enregistrements d'attributs de données en ligne, les enregistrements d'attributs de données en fourche et les enregistrements d'attributs d'extension. Les enregistrements d'attributs de données en ligne stockent de petits attributs qui peuvent tenir dans l'enregistrement lui-même. Les enregistrements Fork Data Attribute contiennent des références à un maximum de huit éléments qui peuvent contenir des attributs plus importants. Les attributs d'extension sont utilisés pour étendre un enregistrement d'attribut de données en fourche lorsque ses huit enregistrements d'extension sont déjà utilisés."

AIUI, les données stockées dans (ou référencées à partir de) le fichier d'attributs (qu'il s'agisse de données en ligne, de données de fourche ou d'attributs d'extension) sont appelées attributs étendus.

Ce sont les structures de données, alors comment sont-elles utilisées ?

AIUI, les premières versions du système d'exploitation (probablement des versions antérieures à 10.4 Tiger, qui John Siracusa semble indiquer qu'il y a eu des changements majeurs dans ce domaine), a pointé vers la fourche de données et la fourche de ressources du fichier catalogue.

AIUI, une fois que nous sommes arrivés à 10.4 Tiger, le fichier d'attributs devient largement utilisé pour stocker toutes sortes de données.

Il est possible (mais je ne le sais pas) qu'à partir de la version 10.4, les fourchettes de ressources soient indiquées à partir du fichier d'attributs. En réponse à votre première question, je dirais que les bifurcations nommées sont des attributs étendus, à moins qu'il ne s'agisse d'une bifurcation de ressource, et que la bifurcation de ressource soit référencée à partir du fichier de catalogue.

Le problème de savoir comment les choses sont implémentées est que pour préserver la compatibilité ascendante, et probablement particulièrement pour supporter l'accès aux systèmes de fichiers écrits par une version de Mac OS à partir d'une autre version, différentes choses et des mélanges de choses doivent être supportés de manière transparente.

Les outils normaux de la ligne de commande du terminal ne nous permettent pas de savoir où se trouvent réellement les données.

Ainsi, l'accès à rsrc pourrait suggérer que l'on accède à la fourchette de ressources du fichier catalogue.

$ ls -l Icon^M/rsrc
-rwxr-xr-x  1 root  admin  486 23 Jul  2004 Icon?/rsrc

Cependant, nous savons que, même si la syntaxe ressemble à un fichier sous la rubrique Icon^M est accédé, ce n'est pas vraiment le cas, parce que

$ ls -lR Icon^M
-rwxr-xr-x@ 1 root  admin  0 23 Jul  2004 Icon?

Apple a donc mis en place un cas spécial pour Resource Forks.

Si à la place nous faisons

$ ls -l@
-rwxr-xr-x@ 1 root  admin   0 23 Jul  2004 Icon?
    com.apple.FinderInfo    32 
    com.apple.ResourceFork  486 

Cela suggère que nous accédons au fichier des attributs. Mais là encore, l'implémentation de ls peut avoir un cas particulier pour Resource Forks.

John Siracusa fait remarquer ici que les listes ACL sont stockées en tant qu'"Attributs étendus", mais qu'elles sont spécialement masquées pour ne pas être affichées dans la base de données de l'ACL. xattr . Donc, une fois de plus, il y a un traitement spécial des cas dans l'implémentation de xattr.

(Notez que ce traitement des cas particuliers peut se trouver dans le code de l'outil, ou dans le code des API sous-jacentes auxquelles les outils ont accès).

GregW, si vous voyez ceci, ce serait bien d'avoir une opinion plus experte pour savoir si je suis sur la bonne voie ou si je suis juste désespérément confus.