John Siracusa

Les attributs étendus

Tiger inclut le support de la famille de fonctions "xattr" dans la couche BSD : getxattr(), setxattr(), removexattr(), listxattr(), plus les variantes préfixées par "f" qui concernent les descripteurs de fichiers plutôt que les chemins. Les fonctions "xattr" existent depuis des années sous différentes formes dans d'autres versions d'Unix, mais c'est leur première apparition sous Mac OS X. La page de manuel Unix explique :

Les attributs étendus étendent les attributs de base associés aux fichiers et aux répertoires dans un système de fichiers. Ils sont stockés sous forme de paires nom:donnée associées aux objets du système de fichier.

Le nom d'un attribut étendu est une simple chaîne UTF-8 terminée par NULL. La valeur est un pointeur sur un tampon de données contenant des donnés textuelles ou binaires, qui doivent être associées avec l'attribut étendu.

Pour le cas où ce n'aurait pas encore fait tilt : après plus de quatre ans d'attente, Apple a maintenant implanté le support de méta-données arbitrairement extensibles dans le système de fichiers !.

Je suis assez obsédé pour avoir voulu terminer cette phrase par un point d'exclamation après l'avoir écrite en gras. Et puis j'ai décidé de ménager le lecteur occasionnel. Mais si vous le lisez ainsi de votre plein gré, alors, c'est bien, mon frère.

Eh oui, c'est tout à fait vrai. J'ai engagé Marquis Logan ("nibs") le régulateur depuis longtemps de Macintoshian Achaia du Big Nerd Ranch à créer un outil en ligne de commande qui vous permet de juger par vous-même. Il alla au delà de son devoir, en enveloppant les APIs BSD dans un ensemble de classes à la manière de Core Foundation. Vous pouvez télécharger les sources ou le code binaire. (Il vous faudra XCode pour reconstruire la source). Voici un exemple du programme, bien nommé xattr, en action:

D'abord, je crée un petit fichier texte pour pouvoir jouer :
listing

Puis, j'ajoute, je liste, je modifie, j'efface quelques attributs arbitraires
listing

Je n'ai rien dans ma manche, promis.
listing

Non, il n'y a pas non plus de fourche ressource
listing

Sous Tiger, la plupart des outils en ligne de commande reconnaissent les méta-données aussi... listing

... mais quelques-uns réclament un drapeau supplémentaire : (Lisez la Doc, pour vous en assurer)
listing

Tout cela se passe sur un volume HFS+ ; pas du HFSX, non, un simple vieux HFS+. Comme pressenti en Mars 2004, un volume HFS+ normal a tout à fait la possibilité des stocker un nombre arbitraire d'attributs. Les APIs xattr de Tiger tirent (enfin) parti de cette possibilité. Aucun nouveau format de volume, et aucun reformatage nécessaire.

Le support pour des formats de volume moindre est fourni par le fichier classique ._nom_de_fichier (point souligné).
listing

Dans les versions précédentes de Mac OS X, les fichiers préfixés par "._" contenaient toutes les méta-données pour leur partenaire non-préfixé, que le format natif du volume ne peut pas rassembler dans un seul fichier : les fourches de ressources, les drapeaux, les dates, et maintenant dans Tiger, les attributs étendus.

Les APIs des attributs étendus cachent les détails, et les autres outils en ligne de commande ont été mis à jour pour utiliser les nouvelles APIs quand c'est nécessaire. Par exemple, voyez ce qui se passe quand la commande cp est utilisée pour copier un fichier avec des attributs étendus ("file2", dans l'exemple précédent), d'un volume HFS+ vers un volume FAT (Ms-DOS).
listing

Et voilà ! Un fichier préfixé avec ._ (Maintenant c'est une démo que vous ne verrez jamais Jobs proposer dans une présentation d'introduction).

Les attributs étendus : usage, et limitations

L'implémentation dans Tiger des attributs étendus est "préliminaire" dans de nombreux sens du terme. Il y a certaines limitations au nombre et à la taille des noms d'attributs et des valeurs. Les noms d'attributs peuvent avoir jusqu'à 128 octets de long, et doivent être des caractères Unicode (UTF-8). Les valeurs peuvent être des données arbitraires jusqu'à 4 K octet. (Il n'y a pas réellement de limite matérielle, mais Apple recommande de rester en dessous de 4 K octets pour le moment).

Bien qu'il n'y ait pas de limite matérielle au nombre d'attributs qu'on peut associer à un fichier, le temps que cela prend quand on ajoute un attribut augmente considérablement au delà de quelques milliers d'attributs. Si on lance quelque chose comme :
listing

pendant quelques minutes, on obtient environ 7 000 attribus. J'ai pensé que peut-être, la performance de l'insertion des attributs pouvait baisser à cause de collisions de hashage, et j'ai essayé de rajouter une chaîne aléatoire au début du nom de chaque attribut. la performance ne s'est pas réellement améliorée. Je ne sais pas où est le problème. J'ai continué à faire tourner, et j'ai obtenu un fichier avec plus de 12 000 attributs, mais cela a pris un moment.

Il est intéressant de noter que c'est seulement l'addition des attributs qui se ralentit si vite. Le listing des 12 000 (et plus) attributs est presque instantané. Effacer un attribut est aussi rapide.

Ce genre de test peut sembler académique, mais j'essaie de me faire un idée de la façon dont se comporte HFS+ dans son nouveau rôle. J'avais espéré, demandé, et j'attends encore maintenant d'Apple (dans mes moments optimistes), un système de fichiers gérant des méta-données avec des performances élevées. Utiliser HFS+ pour ce travail me convient, mais je ne peux pas m'empêcher d'espérer que la puissance du système de fichiers Be fasse son chemin sur la plate-forme Mac. (Le support de BFS pour la création d'index d'attributs résidant sur le système de fichier , et pour des recherches et des notifications en temps réel est digne d'être noté. Mais j'en aurai plus à dire là dessus plus tard.)

La limite à 128 octets du nom des attributs est raisonnable, mais rappelez vous qu'il n'y a qu'une seul espace de noms pour les attributs. Une politique d'isolation est indispensable ; après tout, on ne peut pas avoir 5 programmes qui essaient tous d'écrire dans l'attribut "name".

Pour résoudre ce problème, Apple recommande d'utiliser le schéma de noms DNS-inverse (par exemple com.apple.itunes.artist), mais avec les points remplacés par des sous-lignés (underscore) pour éviter les conflits avec les conventions d'écriture des noms utilisées par le système de codage clé/valeur dans Cocoa.

Le style de nommage DSN-inverse a d'abord été largement utilisé dans le langage de programmation java, comme un moyen de séparer le code en espaces de nommage. Il est devenu de plus en plus courant depuis.
Le style est appellé DNS-inverse parce qu'il utilise les identificateurs d'un système de noms de domaine (DNS) à reculons, élément par élément. Par exemple, Apple possède le nom de domaine developer.apple.com, et l'équivalent en DNS_inverse est com.apple.developper.
Le système des noms de domaine a déjà une autorité de contrôle bien établie, et un système d'arbitrage. Le style de nommage DNS-inverse se branche sur cette infrastructure. C'est un si grand avantage que n'importe quel système de noms d'usage très répandu qui choisit de ne pas utiliser le DNS-inverse commet sans doute une grave faute.

La dernière limitation, et peut-être la plus importante de l'implémentation des attributs étendus dans Tiger peut être considérée aussi comme une caractéristique. Les APIs d'attribut étendu n'existent que dans la couche BSD. En ce moment, il n'y a pas d'interfaces Carbon, Cocoa, ou même Core Foundation avec elles. Si une application veut utiliser les attributs étendus, elle doit faire appel aux APIs BSD (qui sont de très bas niveau).

Dans le passé, Apple a introduit de nombreuses technologies à partir de la base, en fournissant d'abord les implémentations BSD, puis en rajoutant plus tard des APIs de plus haut niveau. La couche BSD doit normalement venir la première, ou au moins, simultanément, puisque la plupart des APIs de plus haut niveau dans Mac OS X déclenche à l'occasion un ou plusieurs appels de fonctions du niveau BSD. Ceci est particulièrement vrai pour les entrées/sorties de fichiers.

Dans Tiger, les attributs étendus se trouvent en test grandeur nature. Les APIs existent, HFS+ les supporte nativement, et la plupart des outils de niveau BSD ont été mis à jour pour les prendre en compte. Mais jusqu'à ce qu'il y ait des APIs Carbon, Cocoa, ou Core Foundation qui puissent tirer parti et explicitement utiliser ces nouvelles caractéristiques, les attributs étendus seront hors de portée de radar des applications traditionnelles (GUI) de Mac OS X.

C'est dommage, parce qu'il y a des tas d'utilsations possibles des attributs étendus, comme la prochaine section va nous le montrer.