Confusion sur les métadonnées | Named Forks | Attributs étendus | Fourchette de ressources - HFS +

Je pense qu'il y a une certaine confusion générale sur la relation entre ces quatre éléments dispersés sur le Web. Je voulais que tout soit réglé.

1. Les fourches nommées sont-elles les mêmes que les attributs étendus ? Sinon, quels sont les attributs étendus?
2. Le fork de ressources est-il toujours implémenté en tant que fork ou en tant qu'attribut étendu ? S'il est mis en œuvre d'une autre manière, alors comment?
3. Les métadonnées stockées dans un fichier (créateur, date de modification ...) y a-t-il une relation ou un chevauchement terminologique entre les trois autres mentionnés. Un exemple serait, sont des attributs étendus juste des paires de métadonnées supplémentaires (clé + valeur) stockées sur un fichier.

Toutes les réponses qui pourraient clarifier la façon dont ces quatre éléments sont interdépendants, en particulier en ce qui concerne les trois questions, seraient grandement appréciées et contribueraient au règlement des différends que je vois se produire dans différentes ressources.

La confusion vient du fait que la relation entre ces concepts est complexe et a changé au fil du temps. Dans les systèmes actuels, la différence entre une fourchette nommée et un attribut étendu est largement académique.

Pour un attribut étendu, les données réelles sont stockées dans l'enregistrement de données d'attribut.

Pour un fork, ce qui est stocké est la liste des blocs d'allocation de disque qui contiennent les données. Une fourchette de ressources est toujours une fourchette.

Les métadonnées de base du système de fichiers sont stockées dans des éléments dédiés de l'enregistrement du système de fichiers lui-même, indépendamment des attributs et des références de fourches nommées.

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 que "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 des API au niveau du programme et des outils comme ls ou cp est un moyen de masquer de nombreuses différences entre les concepts. "

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

AIUI, HFS + possède également (copié de Wikipedia HFS +) un "fichier d'attributs [qui] est un nouvel arbre B 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: Enregistrements d'attribut de données en ligne, enregistrements d'attribut de données de fourche et enregistrements d'attribut d'extension. Les enregistrements d'attribut de données en ligne stockent de petits attributs qui peuvent tenir dans l'enregistrement lui-même. Les enregistrements d'attribut de données de fourche contiennent des références à un maximum de huit extensions pouvant contenir des attributs plus grands. Les attributs d'extension sont utilisé pour étendre un enregistrement d'attribut de données Fork lorsque ses huit enregistrements d'extension sont déjà utilisés. "

AIUI, les données stockées dans (ou référencées depuis) ​​le fichier d'attributs (qu'elles soient en ligne, données de fourche ou 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 (peut-être les versions antérieures à 10.4 Tiger, que John Siracusa semble indiquer avoir eu des changements majeurs dans ce domaine), pointaient la fourchette de données et la fourchette de ressources du fichier de catalogue.

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

Il est possible (mais je ne sais pas) qu'en 10.4 et après, toutes les ressources Forks soient pointées depuis le fichier d'attributs. C'est-à-dire en réponse à votre première question, je dirais que les fourches nommées sont des attributs étendus, à moins qu'elles ne soient la ressource Fork et que la ressource Fork 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é descendante, et probablement particulièrement pour prendre en charge l'accès aux systèmes de fichiers écrits par une version de Mac OS à partir d'une autre version, différentes choses et mélanges de choses doivent être pris en charge de manière transparente.

Nous ne pouvons pas dire à partir des outils de ligne de commande Terminal Server normaux où les données sont réellement conservées.

Ainsi, l'accès à rsrcpeut suggérer que la fourchette de ressources du fichier catalogue est en cours d'accès.

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

Cependant, nous savons que bien que la syntaxe ressemble à un fichier sous le Icon^Mrépertoire en cours d'accès, ce n'est pas vraiment le cas, car

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

Apple a donc implémenté un cas spécial pour Resource Forks.

Si au contraire nous le 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 d'attributs. Mais encore une fois, la mise en œuvre de lspeut avoir un cas particulier pour Resource Forks.

John Siracusa souligne ici que les listes ACL sont stockées en tant qu '«attributs étendus», mais sont spécialement masquées afin qu'elles ne soient pas affichées dans xattr. Encore une fois, il existe un traitement de cas particulier dans la mise en œuvre de xattr.

(Notez que ce traitement de cas spécial peut être dans le code de l'outil ou dans le code des API sous-jacentes auxquelles les outils accèdent.)

GregW, si vous voyez cela, ce serait bien d'avoir une opinion plus experte pour savoir si je suis dans la bonne direction, ou simplement désespérément confus.