Project:Omega.org

Par Apple Computer, Inc. © 2002 (Dernière mise à jour 17 Juin 2002),

Traduit par Thierry, 3/10/2002.

Note du traducteur : Sous Mac OS 9, tout était facile. L’utilisateur avait une vue parfaite des dossiers système et pouvait sans trop de difficultés en manipuler les contenus. Qui n’a pas un jour déplacer une extension à la main vers le dossier “Extensions désactivées” pour la rendre inactive ? Sous Mac OS X, plus rien à voir. Malgré les efforts d’Apple pour éviter que nous, anciens utilisateurs, ne soyons pas trop déconcertés, il n’en reste pas moins que l’ensemble continue à être assez opaque. Cette traduction va donc dans le sens d’une clarification générale du système Mac OS X et de, notamment, l’organisation de son File System. Bien évidemment, la population visée en premier lieu par cet article est celle des développeurs. J’ajouterai enfin que les noms de répertoire ont été laissés sous leur forme anglaise. Pourquoi ? Avec les premières versions de Mac OS X, tous les répertoires avaient des noms anglais. Avec Jaguar, certains répertoires ont été francisés (Library est devenu Bibliothèque par exemple). Seulement, depuis la mise à jour 10.2.1, ces noms de répertoire sont retournés à leur valeur originelle ! Pire encore, si vous placez par exemple le dossier /Applications/Utilities dans le Dock, celui s’appèlera Utilitaires et les noms des programmes contenus seront en français (alors que dans le Finder les affiche en anglais) !!! J’en ai perdu mon latin et j’ai donc décidé de maintenir les dénominations anglaises.

Une astuce permet néanmoins de récupérer les noms localisés des dossiers : sous le Terminal et via pico, créez des fichiers nommés “.localized” dans chaque dossier que vous souhaitez localiser (Merci à un de nos lecteurs qui nous a founit cette astuce).

Introduction

D’un point de vue architectural, Mac OS X implémente plusieurs systèmes de fichiers, les plus importants étant Mac OS Extended (HFS+), Mac OS Standard (HFS), UFS, ISO 9660, NFS, et AFP. Mais d’un point de vue utilisateur, les systèmes de fichiers sont monolithiques; quand des utilisateurs copient, déplacent ou font glisser des fichiers et des dossiers, il y a (ou il semble qu’il y ait) un seul système de fichiers.

Cet article observent les systèmes de fichiers des deux points de vue et aborde des sujets qui revêtent un intérêt pour les développeurs. Il décrit d’abord l’implémentation standard des répertoires dans Mac OS X—là où les éléments tels que les applications, les documents, les frameworks et les ressources sont placés dans un environnement réseau multi-utilisateur. Il décrit ensuite les différences et les problèmes d’interopérabilité entre les nombreux systèmes de fichiers, et plus particulièrement avec les systèmes dominants : HFS+ and UFS. Il explique aussi l’implémentation des resource forks HFS et des politiques suivies pour cette implémentation.

Comment le système de fichiers est organisé

Sous Mac OS X, presque tous les fichiers ont leur place dans le système de fichiers — un emplacement de répertoire standard pour les fichiers de ce type. Pour les utilisateurs, cela ne veut pas dire qu’ils doivent absolument placer leurs applications et les ressources associées dans l’emplacement recommandé. Après tout, les applications sont conçus de façon à pouvoir tourner quelque soit l’endroit où elles sont installées. Par contre, si les utilisateurs ne mettent pas certaines choses à des endroits où le logiciel système les attend, ils perdent certains avantages de Mac OS X. Par exemple, le Finder remplit une base de données applicative en cherchant d’abord dans les emplacements standard normalement assignés aux applications. En conséquence, un document appartenant à une application qui n’est pas située dans un de ces emplacements ne pourra pas être ouvert immédiatement par un double-clic.

Avant d’explorer la rationalité de l’organisation du système de fichiers, considérons ce que le Finder affiche au plus haut niveau de ce système. La liste suivante illustre une hypothétique installation.

Liste 1: Le niveau maximal d’un échantillon de système de fichier Mac OS X

/Mac OS X/ /Network/ /OtherVolumes/

L’organisation d’un système de fichiers est souvent représentée sous la forme d’une arborescence hiérarchique qui part d’une racine (root). A la racine d’un système de fichiers Mac OS X typique (racine indiquée par un “/” initial) on trouve les éléments suivants :

• /Mac OS X/—Le volume à partir duquel le système d’exploitation démarre et sur lequel les logiciels système et les ressources sont installées. Ce volume est en général un disque dur formaté en volume Mac OS Extended (HFS+) — bien qu’il puisse être un volume HFS. Le nom “Mac OS X” est le nom par défaut que l’utilisateur peut changer.
• /Network/—La racine d’un réseau local monté sur le système de l’utilisateur. Le répertoire /Network/ (dont l’icône est un globe) apparaît toujours que l’utilisateur soit connecté ou pas au réseau.
• /OtherVolumes/—Représente un ou plusieurs périphériques externes ou internes qui ne font pas office de volume de démarrage. Cela comprend les lecteurs Zip, les lecteurs de CD-ROM, les appareils photo numériques, les serveurs réseau tout autant que les disques durs et leurs partitions. (Le nom “OtherVolumes” n’est qu’une représentation; le nom réel de chaque volume connecté sera différent).
  Tous les volumes qui ne sont pas des volumes de démarrage appparaissent quand ils sont montés et disparaissent quand ils sont éjectés. Une exception concerne le volume iDisk de l’utilisateur qui apparaît même quand il n’est pas monté.

L’organisation physique des volumes est quelque peu différente de ce que le Finder présente à l’utilisateur. Si vous jetiez un oeil à la structure des répertoires en utilisant le Terminal, vous verriez que le volume de démarrage est monté au niveau de la racine (/) et que les autres volumes sont situés dans /Volumes/. Le Finder fournit cette abstraction pour prodiguer une interface Mac OS plus traditionnelle au système UNIX sousjacent.

Situées aussi au niveau racine, mais cachées à l’utilisateur par le Finder, nous trouvons les répertoires BSD standard tels que /usr, /bin, et /etc.

Les domaines du File-System

Sur un système mutli-utilisateur, le contrôle des accès aux ressources système est important pour maintenir la stabilité du système. Mac OS X comporte plusieurs domaines dans le système de fichiers, chacun d’eux comportant un espace de stockage pour les ressources organisé en un ensemble établi de répertoires. L’accès aux ressources de chaque domaine est déterminé par les permissions de l’utilisateur actif.

Il y a quatre domaines, chacun d’entre eux est décrit dans la liste suivante :

• User. Le domaine User contient des ressources spécifiques à l’utilisateur qui est connecté sur le système. Ce domaine est défini par le répertoire Départ de l’utilisateur, qui peut être situé soit sur le volume de démarrage (/Mac OS X/) ou sur un réseau. L’utillisateur contrôle entièrement tout ce qui va dans ce domaine.
• Local. Le domaine Local contient des ressources telles que les applications et les documents qui sont partagés par tous les utilisateurs d’un système particulier, mais qui ne sont pas requis par ce système pour qu’il puisse tourner. Le domaine Local ne correspond par à un seul répertoire physique mais consiste par contre en plusieurs répertoires du volume local de démarrage (racine). Les utilisateurs dotés de privilèges administrateur peuvent ajouter, retirer et modifier des éléments dans ce domaine.
• Network. Le domaine Network contient des ressources telles que des applications et des documents qui sont partagés par tous les utilisateurs sur un réseau local. Les éléments de ce domaine sont en général situés sur des serveurs et sont placés sous le contrôle d’un administrateur réseau.
• System. Le domaine System contient le logiciel système installé par Apple. Les ressources du domaine système sont requises par le système pour une exécution correcte. Les éléments de ce dmaine sont situés sur le volume de démarrage (racine). Les utilisateurs ne peuvent pas ajouter, retirer ou modifier des éléments dans ce domaine.

Le domaine d’une ressource donnée détermine son applicabilité ou accessibilité à l’utilisateur du système. Par exemple, une police installée dans le répertoire départ d’un utilisateur n’est accessible que par cet utilisateur. Si un administrateur avait installé cette même police dans le domaine réseau, tous les utilisateurs du réseau y auraient accès.

Au sein de chaque domaine Mac OS X propose un ensemble de répertoires initiaux pour organiser les ressources contenues. Mac OS X utilise des noms de répertoire identiques dans chaque domaine pour y stocker des ressources du même type. Cette cohérence simplifie le traitement de recherche de ressources à la fois pour l’utilisateur et pour les méthodes systèmes qui utilisent ces ressources. Quand le système doit trouver une ressource, il cherche séquentiellement dans les domaines jusqu’à ce qu’il la trouve. Les recherches commencent dans le domaine User et se poursuivent dans les domaines Local, Network et System dans cet ordre.

Votre code ne devra jamais présumer du chemin d’accès à une ressource au sein d’un domaine puisque ces chemins pourraient changer dans le futur. Apple fournit des API pour les accès aux chemins standard du système de fichiers. Vous devrez toujours utiliser ces API pour localiser des ressources système. Voir le paragraphe sur ce sujet plus loin dans l’article.

Les sections suivantes décrivent en détail chacun des domaines du système de fichiers, y compris cartains répertoires standard de ces domaines.

Le domaine User

Le domaine User contient des ressources spécifiques à un utilisateur. Ce domaine est représenté par le répertoire Départ de l’utilisateur connecté. Chaque utilisateur d’un ordinateur Mac OS X doit avoir un compte sur cet ordinateur ou sur le réseau local auquel l’ordinateur est connecté. A chaque compte utilisateur est assigné un espace au sein du système de fichiers, appelé répertoire Départ. Ce répertoire est l’endroit où les programmes, les ressources et les documents utilisateurs résident. Le nom de chaque répertoire Départ est basé sur le nom court d’identification de l’utilisateur qui doit être unique.

Le domaine User rend possible la personnalisation complète pour chaque utilisateur de son environnement de travail. Quand un utilisateur se connecte, le Finder restaure l’environnement de travail et les réglages de l’utilisateur à leur état précédent en se basant sur les préférences du domaine utilisateur. De manière similaire, les programmes et autres logiciels système utilisent des informations du domaine utilisateur pour restaurer des préférences applicatives, des réglages réseau, des réglages mail, des polices, des profils ColorSync et d’autres réglages.

L’emplacement du répertoire Départ—domaine user—est dépendant du compte utilisateur. Si le compte utilisateur est local, le répertoire Départ sera dans le répertoire Users du volume de démarrage. Si le compte utilisateur est sur un réseau local, le répertoire Départ sera sur un serveur. Quel que soit l’emplacement physique du répertoire Départ, Mac OS X utilise la convention UNIX, le caractère tilde “~“, pour indiquer le répertoire Départ dans certaines situations. Ce caractère peut être utilisé en combinaison avec d’autres répertoires ou noms d’utilisateur pour spécifier des répertoires utilisateur spécifiques. Le tableau suivant illustre ce concept.

Table 1: Utilisations du tilde pour indiquer des emplacements dans des répertoires Départ
~	Niveau le plus haut du répertoire Départ de l’utilisateur actif
~/Library/Fonts	Là où les polices sont stockées dans le répertoire Départ de l’utilisateur actif
~Steve	Niveau le plus haut du répertoire Départ de l’utilisateur Steve

Le répertoire Départ de tout nouvel utilisateur est constitué par défaut de quelques répertoires et ressources. Ces répertoires sont le miroir de ceux trouvés dans les comptes iDisk (Pour plus d’informations sur iDisk, voir la section iTools sur http://www.apple.com). Ces répertoires par défaut sont les mêmes quel que soit l’endroit où est créé le répertoire Départ. Le tableau suivant liste les sous-répertoires standard d’un répertoire Départ :

Table 2 Contenus des répetoires Départ par défaut
Répertoires	Descriptions
Desktop	Contient les éléments que le Finder affiche sur le bureau pour l’utilisateur actif.
Documents	Contient les documents personnels de l’utilisateur.
Library	Contient les réglages applicatifs, les préférences et d’autres ressources système spécifiques à l’utilisateur. Voir “Le répertoire Library”.
Movies	Contient des films numériques au format QuickTime et sous d’autres formats.
Music	Contient des fichiers de musique digitale (.aiff, .mp3, et d’autres formats).
Pictures	Contient des fichiers images sous divers formats.
Public	Contient des éléments que l’utilisateur désire partager avec d’autres utilisateurs. Par défaut, ce répertoire est accessible aux autres.
Sites	Contient des pages Web du site Web personnel de l’utilisateur. Le Partage Web doit être activé pour que ces pages soient accessibles aux autres utilisateurs.

Quand un compte utilisateur est créé, un répertoire Applications n’est pas automatiquement ajouté au répertoire Départ. Cependant, les utilisateurs peuvent créer ce répertoire et y placer leurs applications. Le système recherche automatiquement des applications dans ce répertoire.

Le système protège les fichiers et les répertoires du répertoire Départ des interférences externes en appliquant un ensemble d’autorisations par défaut que l’utilisateur peut changer quand il le souhaite. Tout nouveau dossier créé par l’utilisateur hérite des privilèges du répertoire parent.

En plus des répertoires individuels, le répertoire Users contient un sous-répertoire Shared. Ce répertoire est accessible par tout utilisateur du système local. Tout utilisateur peut y écrire, y récupérer et y lire des documents. Bien que ce répertoire ne soit pas vraiment associé au domaine User, il fournit une manière commode pour échanger des documents et autres fichiers.

Le domaine Local

Le domaine Local contient des ressources accessibles sur l’ordinateur mais qui ne sont pas vitales pour le système. Ces ressources sont en général des applications, des utilitaires, des polices personnelles, des éléments personnels d’ouverture de session et des réglages applicatifs globaux. Les répertoires Applications et Library du volume de démarrage contiennent les ressources du domaine local. Ces ressources sont disponibles pour un utilisateur du système local mais ne le sont pas pour les utilisateurs d’autres machines du réseau.

Les administrateurs d’un ordinateur peuvent installer des ressources dans le domaine local si ils souhaitent que ces ressources soient disponibles pour l’ensemble des utilisateurs de l’ordinateur. Apple place ses applications dans les répertoires /Applications et /Applications/Utilities. Les applications et utilitaires de tierce partie devraient aussi être placés dans ces répertoires. Les autres ressources système telles que les polices, les profils ColorSync, les préférences et les plug-ins devraient être placées dans les sous-répertoires appropriés du répertoire Library. Pour en savoir plus sur le répertoire Library, allez voir le paragraphe “Le répertoire Library”.

Le domaine Network

Le domaine Network contient des ressources disponibles pour tous les utilisateurs d’un réseau local. Ces utilisateurs peuvent accéder aux applications, documents et autres ressources de ce domaine, y compris les serveurs AppleShare et Web. La composition exacte d’un domaine réseau dépend de la politique de l’institution ou de l’entreprise. L’implementation d’un domaine réseau est de la responsabilité de l’administrateur réseau.

Le tableau ci-dessous liste les répertoires standard d’un domaine Réseau ainsi qu’une description de leur contenus.

Table 3 Répertoires réseau
Location	Description
/Network/Applications	Contient des applications qui peuvent être lancées par tous les utilisateurs du réseau local.
/Network/Library	Contient des ressources—telles que des plug-ins, des fichiers sons, de la documentation, des frameworks, des coleurs et des polices—disponibles pour tous les utilisateurs du réseau local. Voir “Le répertoire Library”.
/Network/Servers	Contient les points d’ancrage des serveurs de fichiers NFS qui constituent le réseau local.
/Network/Users/	Contient les dossiers Départ de tous les utilisateurs du réseau local. C’est l’emplacement par défaut des dossiers Départ. Les dossiers Départ des utilisateurs peuvent aussi être placés sur d’autres serveurs.

Le domaine System

Le domaine System contient des ressources vitales pour Mac OS X. Toutes les ressources du domaine système sont situées dans le répertoire /System du volume de démarrage. Ces ressources sont fournies par Apple et seul l’utilisateur root peut modifier le contenu de ces répertoires. Les utilisateurs administratifs et les applications ne peuvent pas installer de ressources dans le domaine système ou en modifier le contenu directement.

Par défaut, le répertoire /System contient uniquement un sous-répertoire Library. Ce sous-répertoire contient des répertoires du même type que ceux contenus dans les autres répertoires Library du système. Cependant, dans le domaine système, ce répertoire contient aussi les services noyau (core services), les frameworks et les applications qui constituent Mac OS X. Pour en savoir plus sur le répertoire Library, allez voir le paragraphe “Le répertoire Library”.

Bien que l’environnement de compatibilité Classic contienne des ressources systèmes, il n’est pas considéré comme faisant partie du domaine système. Pour plus d’informations sur l’environnement Classic, se reporter à “Répertoires de l’Environnement Classic”.

Le répertoire Library

NDT : Sur certaines versions françaises de Mac OS X, ce répertoire peut s’appeler Bibliothèque.

Le répertoire Library est un répertoire spécial utilisé pour stocker des ressources spécifiques aux applications et au système. Tout domaine du système de fichier a sa propre copie du répertoire Library, avec des niveaux d’accès fonction du type de domaine. Bien qu’une application puisse se servir de ce répertoire pour stocker des données internes ou des fichiers temporaires, il n’est pas recommandé d’y stocker des applications ou des données utilisateurs. Les applications appartiennent au répertoire /Applications, tandis que les données utilisateurs appartiennent au répertoire Départ de l’utilisateur.

Le répertoire Library contient beaucoup de sous-répertoires standard. Des routines système s’attendent à la présence de beaucoup de ces sous-répertoires, ce n’est donc jamais une bonne idée d’en supprimer un. Cependant, des applications peuvent créer à besoin de nouveaux sous-répertoires pour y stocker des données spécifiques.

Le tableau ci-dessous liste quelques-uns des sous-répertoires qui peuvent apparaître dans le répertoire Library. Cette liste n’est pas complète, mais elle indique quelques-uns des répertoires les plus significatifs pour les développeurs. Les répertoires qui n’apparissent pas dans tous les domaines sont notés de manière appropriée.

Table 4 Sous-répertoires du répertoire /Library
Sous-répertoires	Contenus
Application Support	Plug-ins de tierce partie, applications d’aide, modèles et autres ressources spécifiques à une application. Par convention, ces éléments doivent être placés dans un sous-répertoire propres à l’application. Par exemple, les ressources de l’application MyApp iront dans Application Support/MyApp/. Notez que les ressources créées par le développeur d’une application doivent être placées dans le plackage de l’application. by the developer of an application should go in the application package itself.
Assistants	Programmes qui assistent l’utilisateur dans des taches de configuration ou autres.
Audio	Plug-ins et pilotes de périphériques audio.
ColorPickers	Ressources pour sélectionner des couleurs en fonction d’un modèle, tel que le modèle HLS (Hue Angle, Saturation, Lightness) ou RGB.
ColorSync	Profils et scripts ColorSync.
Components	Composants et extensions du système.
Documentation	Documentations et packages d’aide Apple (dans le sous-répertoire Help) à l’attention des utilisateurs et des admnistrateurs de l’ordinateur. Dans le domaine local, ce répertoire contient contient les aides d’Apple (à part la documentation développeur).
Extensions	Pilotes de périphériques et autres extensions noyau (domaine System uniquement).
Favorites	Liens vers les dossiers, fichiers et sites Web favoris (domaine User seulement).
Fonts	Fichiers de police pour l’affichage et l’impression.
Frameworks	Frameworks et librairies partagées.
Internet Plug-ins	Plug-ins, librairies et filtres pour Internet.
Keyboards	Définitions de claviers.
Mail	Contient les boites à lettres utilisateur (Domaine User seulement).
Preferences	Préférences utilisateur.
Printers	Pilotes d’impression (fournis par les vendeurs) et plug-ins PPD.
QuickTime	Composants et extensions QuickTime.
Scripting Additions	Scripts et ressources de scripting qui étendent les possibilités d’AppleScript.
Sherlock Plug-ins	Plug-ins pour étendre les possibilités de Sherlock.
Sounds	Alertes sonores système.
StartupItems	Scripts et programmes système et de tierce partie à lancer au démarrage.
Web Server	Contenu du serveur Web. Ce répertoire contient les scripts CGI et les pages Web à servir.

Le répertoire Developer

Vous pouvez installer les applications, les outils, la documentation et d’autres ressources pour développer des logiciels Mac OS X puisque le tout est contenu dans un package optionnel. Quand vous installez les outils de développement, l’installateur place tous les composants dans le répertoire Developer, situé sur le volume de démarrage (/Mac OS X).

Le tableau suivant montre le contenu du répertoire Developer.

Table 5 Contenus des sous-répertoires développeur
Répertoire	Contenu
Applications	Applications utilisées pour gérer et construire des projets applicatifs (Project Builder), pour créer des interfaces utilisateur (Interface Builder), et pour effectuer des réglages de performances.
Documentation	Documentation développeur.
Examples	Exemples de projets organisés par thème (Carbon, Java, etc).
Headers	Fichiers spéciaux d’en-tête tels que les en-têtes Carbon “flat”.
Java	Fichiers requis pour Java dans l’environnement applicatif Cocoa.
Makefiles	Fichiers “makefiles” et “jamfiles” pour créer et convertir des projets.
Palettes	Palettes d’Interface Builder fournies par Apple.
PBBundles	Paquets chargeables utilisés par Project Builder.
ProjectBuilder Extras	Plug-ins et modèles de Project Builder.
ProjectTypes	Définitions des types de projet utilisés par Project Builder.
Tools	Outils de développement à ligne de commande, y compris ceux pour créer et manipuler les “resource forks” HFS.

Project Builder définit un ensemble de variables “makefile” que vos projets peuvent utiliser au moment de spécifier des emplacements situés dans les domaines du système de fichiers. Vous devrez utiliser ces variables au lieu de coder en dur les chemins d’accès car ces emplacements sont sujets à changement. Pour avoir une liste complète de ces réglages de construction (y compris les variables “makefile”), se reporter à l’aide Project Builder.

Répertoires de l’Environnement Classic

L’environnement Classic contient plusieurs répertoires utilisés pour le support des applications Classic. Les répertoires de l’environnement Classic sont les répertoires d’une installation Mac OS 9. Mac OS X demande une installation de Mac OS 9.1 (ou ultérieure) pour l’environnement Classic. Si un système a une version antérieure à Mac OS 9 d’installée, l’utilisateur doit installer une version plus récente pour supporter Mac OS X.

Un système peut avoir différentes versions de Mac OS 9 installées sur différentes partitions. Si tel est le cas, le panneau Classic des Préférences Systèmes permet à l’utilisateur de choisir le Mac OS 9 à utiliser pour l’environnement Classic. La première fois que l’utilisateur lance Classic, le système ajoute quelques fichiers nécessaires dans le Dossier Système du volume Mac OS 9. L’utilisateur peut passer d’un environnement Classic à un autre en utilisant le panneau Classic des Préférences Système. Il peut aussi changer le disque de démarrage pour démarrer directement sous Mac OS 9 au lieu de Mac OS X en utilisant les Préférences Systèmes Démarrage.

Quand vous installez Mac OS 9.1 (ou ultérieur) sur un volume, l’installateur crée plusieurs répertoires pour stocker les fichiers systèmes. Le tableau suivant liste les répertoires créés par l’installateur avec une description de leurs contenus. Si vous avez déjà une version de Mac OS X ou de Mac OS 9.1 (ou ultérieur) installée, l’installateur ne devrait pas créer ces répertoires.

Table 6 Répertoires créés par l’installateur Mac OS 9.1 (ou supérieur)
Directory	Description
Applications (Mac OS 9)	Contient les applications et utilitaires Mac OS 9 (Classic).
Documents	Contient des informations spécifiques aux applications. Ce répertoire ne doit être utilisé que par des applications classiques. Les applications Mac OS X doivent stocker les préférences et autres fichiers applicatifs dans le répertoire /Library. Les utilisateurs doivent stocker leur documents dans leur répertoire Départ.
System Folder	Contient les fichiers systèmes de l’environnement Classic.

Quand vous installez Mac OS X sur un système avec Mac OS 9 déjà installé, l’installateur effectue quelques taches supplémentaires pour supporter l’environnement Classic. En particulier, l’installateur de Mac OS X crée un alias du dossier Desktop de Mac OS 9 et le place sur le bureau de l’utilisateur administratif qui a lancé l’installateur. Cet alias contient des liens vers tous les fichiers qui étaient sur le bureau de Mac OS 9 avant l’installation de Mac OS X.

Recherche dans les domaines du système de fichier

Mac OS X comprend deux interfaces publiques de programmation que vous pouvez utiliser pour effectuer des recherches de ressources, de plug-ins et d’autres éléments à l’intérieur de répertoires spécifiques dans des domaines particuliers. Une des ces API—la fonction FindFolder du Folder Manager—est à destination des programmes Carbon. L’autre API—les fonctions et constantes définies dans NSPathUtilities.h du framework System—est à destination de tout autre type de programme.

Ces deux API vous aident à effectuer des recherches d’un élément particulier dans tous les domaines du système de fichiers. Par convention, les recherches démarrent en général par le domaine le plus spécifique et se terminent par le plus général. L’ordre de recherche dans les domaines est donc le suivant :

1. User
2. Local
3. Network
4. System

La plupart des logiciels système suivent cet ordre quand ils recherchent un élément dans tous les domaines. Cependant, vous pouvez chercher dans l’ordre qui sera le plus adapté aux besoins de votre application.

Cacher les extensions de noms de fichier

Dans Mac OS X, le type d’un fichier est identifié en utilisant deux techniques séparées : les types de fichier et les extensions de noms de fichier. Les types de fichier sont communs à ceux de Mac OS 9 et sont stockées sous forme de méta-données de fichier. Les extensions de noms de fichier sont communément utilisés sur des systèmes Windows et UNIX et sont supportés par Mac OS X pour apporter une compatibilité maximale avec les autres systèmes d’exploitation. Cependant, de maniière à préserver l’approche des utilisateur de Macintosh, Mac OS X permet de cacher les extensions de fichier, fichier par fichier.

Chaque fichier du file system comporte maintenant un flag spécial indiquant si l’extension est cachée ou pas. Ce réglage affecte seulement la manière dont est affiché le fichier, cela ne modifie en aucun cas physiquement le nom du fichier dans le file system. Les utilisateurs peuvent aussi cacher toutes les extensions de fichier par les préférences du Finder.

Les applications qui affiche les noms de fichiers dans leur interface utilisateur doivent passer par des routines spéciales pour récupérer le nom d’affichage d’un fichier. Les méthodes Launch Services LSCopyDisplayNameForRef et LSCopyDisplayNameForURL prennent en compte le flag extension quand elles retournent le nom d’un fichier, tout comme le fait la méthode displayNameAtPath du NSFileManager. Votre application devra utiliser ces méthodes seulement si elle doit afficher des noms de fichier dans son interface. Toute autre manipulation interne effectuée par votre application devra toujours utiliser le nom de fichier complet.

Les applications doivent aussi être averties des préférences d’affichage des extensions de fichier quand elles ouvrent ou sauvegardent des fichiers, à savoir :

• Les dialogues de sauvegarde doivent permettre à l’utilisateur de contrôler l’affichage de l’extension.
• Les applications doivent préserver le réglage afficher/cacher existant et l’extension existante quand elles ouvrent ou sauvegardent un document.
• Les applications doivent ajouter une extension appropriée au moment de sauvegarder un nouveau fichier ou au moment de sauvegarder un fichier existant à l’aide de la commande Enregistrer sous.
• Les applications de doivent pas ajouter d’extension ou changer le réglages afficher/cacher d’un fichier qui n’a pas d’extension.

Carbon et Cocoa autorisent tous les deux de cacher les extensions de fichier dans leur boite de sauvegarde respectives. Dans Carbon, vous pouvez positionner l’option de dialogue kNavPreserveSaveFileExtension du dialogue de sauvegarde des services de navigation. Dans Cocoa, vous pouvez utiliser la méthode setCanSelectHiddenExtension: de la classe NSSavePanel pour activer cette fonction. Voir les documentations de références Cocoa et Carbon pour plus d’informations.

Localisation des noms du système de fichiers

Mac OS X supporte plusieurs localisations simultanées pour certains éléments du système de fichiers. Le support de la localisation des éléments du système de fichiers a pour but d’apporter à l’utilisateur une localisation plus complète que celle qu’il ont pu avoir. Auparavant, quand l’utilisateur changeait la langue d’un système, les barres de menus et les éléments d’interface s’adaptaient à cette langue alors que les éléments du système de fichiers, tels que les noms de dossier, gardaient leur nom d’origine. Maintenant, certains noms du système de fichiers changent en fonction de la langue sélectionnée. Le résulttat permet aux utilisateurs de naviguer plus profondément dans la hiérarchie du système de fichiers dans leur langue maternelle.

Mac OS X applique le support de la localisation d’abord aux noms de répertoires et bundles système, y compris les noms des applications. Les noms de répartoire tels que System, Applications et Library parmis d’autres apparaissent maintenant dans la langue sélectionnée par l’utilisateur actif. Les développeurs peuvent aussi tirer profit du support de la localisation pour leurs propres applications et noms de répertoire. Pour plus d’informations sur la localisation des noms d’applications, se reporter à “Localiser les noms de progiciel”. Pour plus d’informations sur la localisation des noms de répertoire, se reporter à “Localiser les noms de répertoire”. Les extensions de fichier ne sont jamais localisées.

Important : Mac OS X ne supporte pas les noms localisés de progiciels et de répertoires dans les environnement Classic et Darwin, tout comme Mac OS X ne supporte pas la localisation des fichiers ordinaires.

Afficher des noms de chemins d’accès localisés

Les développeurs doivent faire attention aux noms localisés du système de fichiers dans leurs applications et les afficher correctement. Les chemins d’accès localisés ne doivent être utilisés que pour l’affichage dans votre interface utilisateur. Vous ne devrez jamais essayer d’utiliser des chemins d’accès localisés pour accéder directement aux fichiers, tout comme vous ne devrez jamais stocker des chemins d’accès personnalisés dans des fichiers de préférences ou des caches internes. La localisation d’un chemin d’accès devra toujours être la dernière étape juste avant l’affichage de ce chemin à l’utilisateur.

Mac OS X apporte plusieurs fonctions pour obtenir un chemin d’accès localisé. Votre application devra toujours utiliser une de ces fonctions pour convertir un chemin d’accès en un chemin localisé immédiatement avant son affichage. En plus de localiser les noms appropriés de répertoires et de progiciels, ces méthodes cachent aussi l’extension du fichier quand le fichier pour lequel elles sont appelées le spécifie ou quand les réglages du Finder sont positionnés pour. Les méthodes LSCopyDisplayNameForRef et LSCopyDisplayNameForURL des Launch Services convertissent des chemins en leur version localisée, tout comme la méthode displayNameAtPath de la classe NSFileManager.

Localiser les noms de progiciels

Les progiciels et applications supportent les noms de fichiers localisés au travers du dispositif existant de localisation des progiciels. Le dossier des ressources d’un progiciel peut contenir plusieurs sous-répertoires .lproj, chacun contenant les ressources localisées propres à une langue. Un des fichiers que vous pouvez placer dans ces sous-répertoires est un fichier InfoPlist.strings, qui stocke les valeurs localisées de clés spéciales. Pour spécifier un nom localisé à votre progiciel, incluez la clé CFBundleDisplayName dans ce fichier et renseignez sa valeur du nom localisé du progiciel.

Au moment de déterminer les noms localisés des progiciels, Mac OS X préfère les noms personnalisés par l’utilisateur aux noms par défaut et aux noms localisés stockés dans le progiciel. Le fichier Info.plist du répertoire Contents du progiciel contient la clé CFBundleDisplayName, dont la valeur correspond au nom d’affichage du progiciel. Si la valeur de cette clé ne correspond pas au nom du progiciel dans le système de fichier, Mac OS X utilise ce dernier comme nom d’affichage. Si les valeurs correspondent, Mac OS X utilise le nom localisé approprié s’il existe, sinon il utilise le nom par défaut.

Les règles de support des noms de progiciels localisés s’appliquent à tous les progiciels, y compris les applications et les frameworks.

Localiser les noms de répertoire

Si votre package applicatif installe des répertoires spécifiques de support, vous pouvez donner des noms localisés à ces répertoires tout comme vous le pouvez pour votre application. La localisation des noms de vos répertoires spécifiques n’est pas obligatoires et peut ne pas être pratique dans certains cas. Si vous ne voulez pas localiser les répertoires de support de votre application, vous ne devrez le faire que pour les répertoires dont le nom est connu à l’avance par votre application. La localisation de répertoires utilisateur spécifiques n’est pas recommandée.

Pour localiser un nom de répertoire, vous devez ajouter l’extension .localized au nom du répertoire et marquer cette extension comme étant cachée par défaut. A l’intérieur de votre répartoire, vous créez alors un sous-répertoire appelé .localized. Dans ce sous-répertoire, vous créez un fichier “strings” pour chaque langue que vous souhaitez supporter. Les fichiers “strings” comportent une seule ligne contenant la version localisée du nom du répertoire. Par exemple, un répertoire Release Notes avec des localisations anglaise, japonaise et allemande aurait la structure suivante :

Release Notes.localized/
.localized/
en.strings
de.strings
ja.strings

A l’intérieur de chaque fichier “strings”, vous feriez correspondre le nom non-localisé du répertoire au nom localisé. Par exemple, pour faire correspondre le nom “Release Notes” à un nom de répertoire localisé, chaque fichier “strings” contiendrait une ligne similaire à ceci :

"Release Notes" = "Localized name"

Note : Beaucoup de répertoires système prédéfinis n’incluent pas l’extension .localized dans leurs noms. Ces répertoires ayant été créés avant l’introduction des noms localisés du système de fichier, une technique de localisation différente est utilisée pour éviter de changer leurs noms. Pour ces répertoires identifiés, Mac OS X teste la présence d’un fichier vide appelé .localized à l’intérieur du répertoire. Si le fichier existe, Mac OS X affiche le nom localisé du répertoire.

Differences entre HFS+ et UFS

Il y a beaucoup de différences significatives entre les deux systèmes de fichiers majeures de Mac OS X : HFS+ et UFS. Dans beaucoup de cas, ces différences ont une influence sur les programmes développés pour Mac OS X. La liste suivante résume les différences majeures entre ces systèmes de fichiers (la plupart de ces propos s’appliquent à HFS comme à HFS+) :

• Sensibilité à la casse. UFS est sensible à la casse; bien que HFS+ ne soit pas sensible à la casse, il la préserve.
• Forks multiples. HFS+ supporte plusieurs forks (et méta-données additionnelles) alors que UFS n’en supporte qu’un seul. (Carbon simule plusieurs forks sur les systèmes de fichiers qui ne les supportent pas, tel que UFS).
• Séparateurs de chemins d’accès. HFS+ utilise “:” comme séparateur alors que UFS frespecte la convention des “/”. Le système fait la transformation de ces séparateurs.
• Dates de modification. HFS+ supporte à la fois les dates de création et de modification sous forme de méta-données; UFS supporte les dates de modification mais pas celle de création. Si vous copiez un fichier avec une commande qui comprend les dates de modification mais pas les dates de création, la commande réinitialisera la date de modification au moment de la création du nouveau fichier créé. Du fait de ce comportement, il est possible d’avoir un fichier avec une date de création ultérieure à celle de modification.
• Fichiers creux et remplissage. UFS supporte les fichiers creux, ce qui permet au système de fichiers de stocker des données dans des fichiers sans avoir à stocker l’espace inutilisé alloué à ces fichiers. HFS+ ne supporte pas les fichiers creux et, en fait, remplit de zéro tous les octets inutilisés alloués à un fichier jusqu’à la fin du fichier.
• Références légères aux éléments du système de fichiers. Voir “Alias et Liens Symboliques”.

En plus, les API historiquement associées à chaque système de fichiers ont parfois des comportements différents. Par exemple, un programme utilisant des API BSD (ou dérivées de BSD) peuvent supprimer un fichier qui est déjà ouvert; d’un autre côté, un programme Carbon ne pourra supprimer un fichier que s’il est fermé.

Alias et Liens Symboliques

Les alias et les liens symboliques sont des références légères aux fichiers et aux dossiers. Les alias sont associés aux formats de volume Mac OS Standard (HFS) et à Mac OS Extended (HFS+); les liens symboliques sont une fonction des systèmes de fichiers UFS. Les alias et les liens symboliques permettent tous les deux des références multiples aux fichiers et aux dossiers sans nécessiter de multiples copies de ces éléments. Avant Mac OS X 10.2, les alias et les liens symboliques se comportaient très différemment quand un fichier ou un dossier était déplacé ou modifié.

A l’origine, les alias localisaient un fichier ou dossier d’abord par son identifiant unique et ensuite par son chemin d’accès absolu. Si vous déplaciez un fichier sur le même volume, tout alias pointant sur ce fichier continuait à pointer le fichier d’origine. Si vous supprimiez le fichier et le remplacer par un autre du même nom, les alias fonctionnaient toujours parce qu’ils pouvaient localiser le fichier par son chemin d’accès absolu. Depuis Mac OS X 10.2, les alias ont renversé cet ordre de recherche en utilisant d’abord le chemin d’accès absolu et l’identifiant unique ensuite.

Du fait que les alias et les liens symboliques utilisent tous les deux un chemin d’accès au fichier pour localiser un fichier, ils offrent maintenant un comportement initial semblable. Si vous remplacez un fichier par un autre du même nom et que vous déplacez l’ancien fichier, l’alias et le lien symbolique pointeront tous les deux vers le nouveaux fichiers. Cependant, si vous déplacez un fichier sans le remplacer, le lien symbolique sera brisé alors que l’alias ne le sera pas.

Sur des systèmes de fichiers HFS et HFS+, chaque fichier et dossier a une identité unique et persistante. Les alias stockent cette identité aux côtés des informations de chemin d’accès. Si une fichier ne peut être trouvé par son chemin d’accès, l’alias tente de localiser le fichier par son identifiant unique. S’il trouve le fichier, l’alias met à jour son enregistrement interne avec les nouvelles informations du chemin d’accès. De manière similaire, si le chemin d’accès est correct mais que l’identifiant unique ne l’est pas, l’alias met à jour son enregistrement interne avec l’identifiant unique du nouveau fichier.

Le Finder et d’autres applications système utilisent maintenant les alias avec ce comportement “chemin d’accès d’abord”. Cependant, les applications peuvent toujours interprêter un alias d’abord par l’identifiant unique en se servant des méthodes de l’Alias Manager.

Si votre application supporte des versions de Mac OS X antérieures à Mac OS X 10.2, vous devrez suivre certaines recommandations au moment de modifier des fichiers. D’abord, pour éditer un fichier, modifiez le fichier existant. Ensuite, si vous devez remplacer un fichier de manière transparente avec une nouvelle version de celui-ci, utilisez FSExchangeObjects pour placer le nouveau à la place de l’ancien. La classe NSDocument utilise déjà des techniques similaires pour mettre à jour le fichier document, maintenant ainsi les alias quand c’est possible.

Resource Forks

(NdT : Les Resource Forks représentent des données incluses dans les en-têtes de fichiers. Quiconque a ouvert une application Classic avec ResEdit, s’est aperçu du nombre considérable de données qui peuvent y être intégrées. Chaînes de caractères, images, icônes, n° de version, …, autant de données liées à une application sont regroupées par thèmes dans le Resource Fork. La traduction de cette appellation étant osée, nous garderons ces termes en anglais).

Avant Mac OS X et Carbon, les ressources d’une application étaient placées dans le Resource fork de l’exécutable de l’application. Cette politique a maintenant changé. Sous Mac OS X et généralement pour les applications Carbon, les ressources doivent être placées dans le data fork d’un fichier ressource séparé, et plus dans le resource fork de l’exécutable.

Les API Carbon lisent et traitent maintenant les ressources placées dans le data fork d’un fichier ressource comme si elles étaient placées dans le resource fork. (En fait, les routines système qui lisent ces ressources—qui sont principalement des fonctions du Resource Manager—prennent en charge la plupart de ces taches pour vous). Si les ressources de votre application sont stockées dans le resource fork, vous pouvez utiliser ces API pour les accéder, mais vous devez maintenant spécifier explicitement le resource fork pour y arriver.

La raison principale de l’externalisation des ressources applicatives hors du resource forks tient dans la volonté de rendre les applications parfaitement opérantes quelque soit le système de fichiers utilisé sans perte de leurs ressources; cela inclue des méthodes telles que des commandes BSD, FTP, email, et des commandes de copie sous DOS ou Windows. La plupart des environnements informatiques, le Web y compris, reconnaissent que les fichiers ne comportant qu’un seul fork, et ont tendance à supprimer le resource fork des fichiers HFS et HFS+.

Même si Apple recommande maintenant de stocker les ressources dans le data fork d’un fichier ressource, cette solution est incomplète. Par exemple, les ressources applicatives stockées dans un seul fichier sont plus difficiles à localiser (NDT : Dans le sens de traduire en langue locale). En plus d’externaliser les ressources, vous devrez suivre le guide de packaging d’une application et effectuer l’une ou l’autre des choses suivantes :

• Placez, dans les aires localisées (ou non localisées) du progiciel, un fichier qui contiendra les ressources applicatives pour ce lieu (ou tous les lieux). Par convention, ce fichier aura une extension .rsrc, bien qu’il puisse n’en avoir une autre ou pas du tout.
• Au lieu de placer toutes les ressources localisées dans un même fichier .rsrc, placez chaque ressource (ou groupe de ressources) dans son propre fichier.

L’image suivante compare comment les ressources peuvent être stockées sous Mac OS X et comment elles le sont sous des systèmes Mac OS anciens.

Figure 1 Ressources du data fork

Bien qu’Apple supporte le modèle “toute-ressource-dans-un-fichier”, elle recommande fortement que les développeurs placent leurs ressources dans des fichiers séparés. L’utilisation émergeante de XML comme manière de spécifier les ressources est une des considérations qui se cache derrière cette recommandation. Carbon comporte un environnement d’exécution (runtime) basé sur XML que des outils comme Interface Builder utilisent pour exporter les interfaces utilisateur au format XML.

Comme pour les applications, les ressources des documents Mac OS X devraient être placées dans le data fork. Les raisons sont les mêmes que celles d’avoir les ressources applicatives dans le data fork. Cela rend possible l’échange de documents sans perte de données entre des systèmes Macintosh et des systèmes non-Macintosh, y compris la plupart des serveurs Web.

Les fichiers résidant sur des systèmes HFS et HFS+ ont leurs attributs Finder stockés dans un fork privé séparé à la fois du resource fork et du data fork. Ces attributs comprennent les codes type et créateur. Mac OS X maintient ces attributs parce qu’ils permettent au Finder d’améliorer l’expérience utilisateur. Dans le même temps, cependant, Apple encourage fortement les développeurs à utiliser les extensions de fichier comme alternative pour identifier les types de documents. Mac OS X s’en tire très bien dans sa reconnaissance et sa gestion des extensions de documents. Si vous copiez un document HFS ou HFS+ vers une plate-forme différente (serveurs Web compris), les extensions permettent de préserver le type de document.

Encodage de fichier et Police

Bien qu’Unicode soit considéré comme format d’encodage natif de Mac OS X, il n’y a pas de mode d’encodage qui soit valable dans toutes les situations. Le mode d’encodage qui est (ou devrait être) utilisé dépend de ce que vous voulez faire et du système de fichier sousjacent.

Par exemple, l’encodage utilisé pour les noms de fichiers diffère d’un système de fichier à un autre. Mac OS Extended (HFS+) utilise une forme particulière d’Unicode pour les noms de fichiers : décomposition canonique d’Unicode 2.1 en format UTF-16 (une séquence de codes sur 16 bits). Le système de fichiers UFS utilise une forme différente d’Unicode pour les noms de fichiers; il autorise tout caractère d’Unicode 2.1 ou ultérieur, mais utilise le format UTF-8 format (une séquence de codes sur 8 bits). Et Mac OS Standard (HFS) utilise l’encodage Mac traditionnel, tel que MacRoman. Notez qu’à cause de ces différences d’implementation, de l’Unicode erroné dans des noms de fichier sur des volumes HFS+ s’affiche correctement sur des systèmes Mac OS 9, mais apparaît toujours avec des caractères tronqués sur Mac OS X.

En plus, tout code appelant des routines système BSD doit s’assurer que les paramètres const *char de ces routines sont en encodage UTF-8. Toute fonction système BSD s’attend à ce que leurs paramètres chaînes de caractères soient encodées en UTF-8 et rien d’autre. De plus, les paramètres chaînes de caractères supportant des noms de fichiers, des chemins d’accès et d’autres entités du système de fichiers doivent être encodées en UTF-8 canonique. Dans une chaîne encodée en UTF-8 canonique, tout caractère décomposable est décomposé; par exemple, é (0×00E9) est représenté sous e (0×0065) + ´ (0×0301). Pour mettre les choses en encodage UTF-8 canonique, utilisez l’API “file-system representation” définie dans Cocoa et dans carbon (Core Foundation compris). Par exemple, pour récupérer une chaîne de caractères en UTF-8 canonique, utilisez la méthode fileSystemRepresentation: de la classe NSString; pour des chaînes UTF-8 non canonique, utilisez la méthode UTF8String.

Si vous utilisez QuickDraw et souhaitez dessiner du texte, vous devrez faire attention à quelques problèmes potentiels. Le Carbon File Manager (Gestionnaire de fichier carbon) comporte des appels au système de fichiers qui retournent de l’encodage Mac et d’autres qui retournent de l’Unicode. Si vous obtenez du texte en Unicode, vous aurez des problèmes pour le dessiner avec QuickDraw Text parce que cette API ne supporte pas directement l’Unicode. D’un autre côté, si vous récupérez du texte en encodage Mac et souhaitez utiliser les API Apple Type Services for Unicode Imaging (ATSUI - Services Apple de modélisation des lettres Unicode) Cocoa ou Carbon, vous devrez le convertir d’abord en Unicode.

De manière générale, l’encodage utilisé dépend de l’API que vous utilisez et pas de la police. Les polices ne sont pas limitées à des encodages particuliers. Les polices TrueType fonts, par exemple, déclare le groupe de glyphes qu’elles implémentent et fournissent des tables d’encodage qui font corespondre ces glyphes à des valeurs de caractères sous des encodages particuliers. Les polices PostScript comportent des tables similaires d’encodage. Plusieurs parties du système d’exploitation savent comment établir la correspondance des caractères d’un encodage à un autre. Cocoa et ATSUI utilisent Unicode comme encodage de destination pour cette correspondance. QuickDraw Text sous Carbon utilise les encodages Mac, sélectionnés en fonction du script auquel correspond la ressource ‘FOND’ de la police.

Les polices installées avec Mac OS X comportent un ensemble très large de caractères qui supportent beaucoup d’encodages et de scripts. Par exemple, Lucida, la police système, supporte le Latin, le Grec, le Cyrillique, l’Arabe, l’Hébreux et le Thaï. Mais si vous dessinez du texte en utilisant QuickDraw Text, vous n’aurez accès qu’au répertoire MacRoman. Pour accéder au reste, vous devez utiliser Cocoa ou ATSUI. Similairement, les polices Hiragino comportent aussi un large répertoire de caractères au-delà de ceux supportés par MacJapanese, et ceux-ci ne sont accessibles qu’au travers de Cocoa ou ATSUI. Cocoa et ATSUI substituent aussi tous les deux les glyphes d’autres polices quand celui qui est demandé n’est pas disponible; cependant, leurs algorithmes de substitution sont différents.

Textes originaux en anglais sur developer.apple.com : Mac OS X Documentation Essentials

Thierry Développement file system, HFS, Mac OS X, UFS