Cette page explique comment Windows NT/2000/XP supporte (sic) les fichiers Macintosh. Il s'agit d'une compilation d'informations disparates et parfois peu connues. La seule ambition de ce texte est de démystifier le sujet, tant pour les spécialistes de NT que pour ceux du Macintosh.
Note : dans ce qui suit, le service standard de NT permettant le support des Macintosh est appelé SFM (Services For Macintosh).
Sommaire
1. La structure des fichiers Macintosh et NTFS
2. Les noms de fichiers Macintosh et l'UNICODE
|
A lire également Sur le site de Soft Experience : Sur d'autres sites, traduits par Soft Experience :
|
1. La structure des fichiers Macintosh et NTFS
Les forks des fichiers Macintosh
Les fichiers Macintosh sont constitués de deux composantes appelées forks :
Par ailleurs, le système du Macintosh maintient des informations concernant le fichier dans le catalogue du disque dur; ces informations permettent de savoir comment lancer l'application associée au fichier, quelle taille mémoire allouer à un programme, et quelle est la signature Type/Creator du fichier.
[Note : le couple Type/Creator (2 fois 4 caractères) est une signature caractéristique du fichier un peu équivalente au suffixe MS/DOS de trois caractères; il commande au Finder du Macintosh l'application associée à un fichier. Voir l'excellente page de Pierre Duhem sur les
Signatures Macintosh
].
Une application Macintosh ayant perdu son resource fork devient un fichier quelconque, non exécutable et non "cliquable".
On remarquera que l'un ou l'autre de ces forks peut être vide ou presque. Ainsi, les fichiers non exécutables possèdent généralement un resource fork très petit ou même inexistant, tandis que les anciennes applications 68K n'ont pas toujours de data fork.
NTFS (New Technology File System) est le système de fichiers natif de Windows NT.
En NTFS, un fichier consiste en plusieurs data streams qui sont un peu la généralisation du concept de fork pour les fichiers Macintosh. Un stream particulier contient les informations de sécurité (droits d'accès, etc.) et un autre stream appelé standard contient les données habituelles, celles qui sont normalement accessibles par les applications. Quand on examine avec l'Explorateur de Windows un fichier "normal" nommé MonFichier, c'est le stream appelé en interne MonFichier::$DATA qui est affiché. Mais il peut exister aussi d'autres streams (alternate streams) liés au stream standard et contenant des méta-données associées au fichier "normal". Ils sont invisibles depuis l'Explorateur de Windows ainsi que depuis la quasi-totalité des applications Windows. Les alternate streams peuvent être considérés comme des sous-fichiers du stream standard et sont introduits par le caractère deux-points, qui, pour cette raison, est un caractère interdit dans les noms de fichiers Windows ; il peut ainsi exister un stream MonFichier:Secret1 (ou plus précisément MonFichier:Secret 1:$DATA ), un autre stream appelé MonFichier:Secret2, etc., tous liés au fichier "normal" MonFichier.
Un dossier NTFS peut également posséder des alternate streams.
Les streams NTFS et la sécurité
Ce paragraphe développe un article de Gé@NT ! n°5 (septembre 1998).
Il est très facile de créer d'autres streams pour un fichier quelconque. Créons par exemple un stream nommé Secret1.txt :
Examinons maintenant le problème :
Si vous tapez
dir MonFichier.txt, le système vous affichera une taille de 4 octets. Si vous tapez
type MonFichier.txt, il affichera effectivement "xxxx". Par contre, si vous tapez
notepad MonFichier.txt:Secret1.txt ou
more <MonFichier.txt:Secret1.txt, il retrouvera et vous affichera "ceci est secret".
Il est également possible de créer un alternate stream à l'aide de la commande
echo
. La commande suivante, par exemple, crée le même alternate steam que précédemment associé au fichier vide
MonFichier.txt :
echo ceci est secret >MonFichier.txt:Secret1.txt
Enfin, la commande echo ceci est secret >:Secret crée un alternate stream associé au dossier en cours (curieusement - si l'on peut dire! - la commande more se plante lorsque l'on tente d'afficher le contenu d'un alternate stream associé à un dossier).
Qu'est-ce que cela veut dire ? Tout simplement que vous venez de créer un stream complètement invisible, géré par NTFS, mais dont les applications courantes n'ont aucune trace ! Analysons un peu plus le problème. Vous avez créé un fichier normal, sur lequel vous pouvez mettre autant de streams que vous le souhaitez (vous pouvez répétez l'opération avec comme noms de streams Secret2, Secret3, etc.) en les gardant complètement invisibles. Vous pouvez y enregistrer des informations personnelles ou privées, mais aussi des virus, ou tout simplement court-circuiter tous les logiciels que votre administrateur NT a mis en place. Vous pouvez donc posséder un fichier "officiel" possédant un seul octet tandis que les alternate streams de ce fichier occupent plusieurs centaines de Mo.
Poursuivons l'expérience en renommant le fichier "normal":
rename MonFichier.txt SonFichier.txt
La commande
more <MonFichier.txt:Secret1.txt affiche alors 'Fichier intouvable', tandis que la commande
more <SonFichier.txt:Secret1.txt affiche bien "ceci est secret".
Effaçons enfin le fichier "normal" : delete SonFichier.txt . Cette fois la commande more <SonFichier.txt:Secret1.txt affiche 'Fichier intouvable'.
Les alternate streams sont donc complètement liés au stream standard qu'est un fichier "normal"; ils lui sont subordonnés lors des opérations de renommage, déplacement, effacement. Il en est de même pour les alternate streams associés à un dossier.
Microsoft ne fournit aucun outil permettant de visualiser les alternate streams ou de gérer leur occupation sur un volume NTFS. Pire, d'après les tests du NT Users Group :
De l'avis de nombre d'experts, le support des streams dans NTFS est une belle fonctionnalité - qui manque par exemple à Unix (lire à ce sujet la discussion
NTFS-like streams
sur l'intérêt d'introduire le support des streams dans le noyau de Linux). Elle est toutefois fort peu utilisée par les applications. En dehors du support des fichiers Macintosh, comme nous le verrons, les streams sont utilisés parfois dans des applications de cryptage de données (cf. par exemple
Jetico BestCrypt
). Windows 2000 utilise également la technique des streams pour stocker les propriétés (Titre, Sujet, Commentaire, Auteur, etc.) que l'on peut associer à tout fichier, un peu à la manière des propriétés des documents Office. Certaines applications comme l'explorateur de Windows 2000 utilisent aussi les streams pour stocker des vignettes (thumbnails) de fichiers images; les vignettes des images sont alors affichées très rapidement.
Mais les streams constituent également une inquiétante possibilité de cheval de Troie et ouvrent de nombreuses possibilités de virus. En septembre 2000, le premier véritable virus utilisant les streams NTFS et appelé
W2K.Stream
est apparu. Les streams NTFS sont également à l'origine de quelques problèmes de sécurité; cf.
ASP vulnerability with Alternate Data Streams
et
File Access Issue with Windows NT Internet Information Server
.
Il existe deux fonctions de l'API Windows NT permettant de déterminer les streams d'un fichier :
Cf. http://www.mvps.org/win32/ntfs/streams.html
L'utilisation de ces APIs dépasse largement le cadre de ce papier, mais vous pouvez télécharger les programmes suivants qui permettent de lister les alternate streams; presque tous sont des outils en mode console :
Les streams NTFS et les forks Macintosh
Lorsque l'on exécute l'un des utilitaires mentionnés ci-dessus sur un dossier NTFS permettant de stocker des fichiers Macintosh - c'est-à-dire sur un sous-dossier d'un dossier défini comme volume Macintosh à l'aide de SFM -, les streams suivants sont détectés pour chaque dossier ou fichier Macintosh :
Un fichier Quark XPress Macintosh nommé Annonce et stocké sur un dossier NTFS géré par SFM possède par exemple :
Une application exécutable comme SimpleText possède lorsqu'elle est stockée sur un dossier NTFS :
Ces noms de streams sont générés et utilisés par le serveur Macintosh standard de NT (SFM). Lorsque l'on utilise d'autres serveurs Macintosh sur NT, d'autres streams peuvent être utilisés. MacServerIP (Cyan Software) maintient par exemple un stream nommé AFP_FileInfo (toujours 80 octets) pour chaque dossier et fichier.
ATTENTION
: on ne doit jamais utiliser un utilitaire tel que DelStream sur les volumes supportant des fichiers Macintosh puisque les streams permettent de stocker les resource forks et les informations Finder des fichiers. L'effet serait identique au déplacement d'un fichier Macintosh d'un volume NTFS vers un volume FAT (qui ne supporte pas les streams) suivi du rapatriement du fichier en question vers le volume NTFS d'origine : on perd le resource fork du fichier qui devient totalement inutilisable. Vous pouvez par contre déplacer sans problèmes un fichier Macintosh d'un dossier NTFS vers un autre avec l'Explorateur de Windows NT (seulement en NT/SP4 ou supérieur; cela ne marche pas en SP3 et encore moins avec l'Explorateur de Win95/98) ; ce programme utilise des API qui permettent de copier ou déplacer l'ensemble des alternate streams associés au fichier : même si le dossier d'accueil n'est pas reconnu par les Macintosh, on ne perd pas le resource fork du fichier Macintosh car les streams sont une notion NTFS indépendante de SFM. Si SFM n'existe pas sur NT Workstation, c'est une limitation purement commerciale de Microsoft ( MacServerIP et ExtremeZ*IP existent sur NT Workstation). Ainsi, il peut être parfois intéressant d'utiliser une machine NT Workstation pour réaliser à bon compte des sauvegardes de fichiers Macintosh stockés sur un serveur NT (cf. notre programme Idem ).Comment afficher le Type et le Creator des fichiers Macintosh depuis Windows NT ?
- Avec l'Explorateur NT
L'affichage des alternate streams
est facile depuis un prompt MS/DOS sur NT à l'aide de la commande de redirection d'entrée (<). Dans le cas du stream
AFP_AfpInfo, cela permet de connaître les codes Type et Creator des fichiers tels qu'ils sont donnés, par exemple, par l'utilitaire ResEdit sur Macintosh. La structure exacte du stream
AFP_AfpInfo dépasse également le cadre de ce papier (voir
NTFS file structure for Mac Volumes
), mais il suffit de savoir que le Type et le Creator sont en positions 17 et 21 du stream, sur une longueur de 4 caractères chacun.
J'ai écrit
TC
, un petit programme très simple qui permet de lire le Type et le Creator depuis l'Explorateur de NT (
overview in English here
):
@echo off
@echo %1
tc <%1:AFP_AfpInfo
pause
Avec l'Explorateur de NT, sélectionnez un fichier Macintosh, par exemple notre fichier XPress
Annonce
.
Cliquez sur le bouton droit. Choisissez
Envoyer vers
, puis
TC.bat
.
La fenêtre MS/DOS affiche le Type=XDOC et le Creator=XPR3 qui sont caractéristiques des documents XPress.
- Avec le programme MacExplorer
J'ai également écrit
MacExplorer
, un programme gratuit permettant l'analyse des fichiers Macintosh stockés sur un serveur Windows NT.
Voici ses principales caractéristiques :
Les streams associés aux volumes SFM
Ce paragraphe s'applique uniquement aux volumes Macintosh définis par le service standard SFM.
Lorsque l'on exécute un utilitaire tel que LADS sur un dossier NT défini comme la racine d'un volume Macintosh, les streams suivants sont détectés:
Tous ces streams sont créés quand le volume Macintosh est défini. AFP_DeskTop et AFP_IdIndex sont ouverts lorsque le volume est initialisé et sont effacés quand le volume est effacé. AFP_AfpInfo n'est pas effacé.
SFM effectue l'initialisation des volumes Macintosh dans l'ordre de leur création. Un volume n'est pas disponible, c'est à dire visible depuis les Macintosh, avant qu'il ne soit complètement initialisé. Donc, si un petit volume a été créé après un grand volume, le petit volume n'est pas disponible avant le grand.
L'indexation du volume est une étape très importante de l'initialisation. Elle consiste à examiner l'intégralité de l'arborescence et à créer une image du volume en mémoire virtuelle. Le stream
AFP_IdIndex contient cet index; il est mis à jour au démarrage et à l'arrêt de SFM. Après l'étape d'indexation initiale, ce stream n'a pas besoin d'être recréé: il est simplement lu au démarrage de SFM et son image est mise à jour avec les changements qui sont intervenus depuis l'arrêt précédent de SFM. Durant l'indexation d'un volume, l'utilisation de la mémoire non paginée de NT augmente considérablement. Mais ce phénomène est temporaire et la mémoire non paginée est libérée à la fin de l'indexation. L'utilisation de la mémoire non paginée au moment de l'indexation dépend du nombre de répertoires dans l'arborescence, mais pas du nombre de fichiers.
L'utilisation de la mémoire virtuelle est également affectée par SFM. On estime grossièrement qu'un ensemble de 10000 fichiers/répertoires utilise 2 Mo de mémoire vive. Il peut donc être utile d'accroître la mémoire virtuelle de NT (Panneau de configuration/Système/Performances) pour prévenir les dégradations de performances avec les volumes qui contiennent plus de 10000 fichiers ou répertoires.
Note : les articles suivants proposent d'autres optimisations. Il s'agit de manipulations de la base de registre NT (à utiliser donc avec les précautions d'usage):
Si le stream
AFP_IdIndex ne peut être mis à jour à l'arrêt de SFM ou s'il est détérioré, un nouveau stream est créé au démarrage suivant. Il peut être utile de mettre à profit cette propriété quand les performances se dégradent ou que des phénomènes inhabituels se produisent (en particulier: icônes de fichiers en double ou plantages lors de transferts de fichiers). Les mécanismes de mise à jour du stream
AFP_IdIndex sont en effet délicats (et probablement non exempts de bugs). Il est donc parfois nécessaire de forcer la réindexation des volumes Macintosh.
L'article
Troubleshooting MacVolume Creation Errors
décrit les différentes méthodes utilisables. La plus simple à mettre en oeuvre est la méthode 4:
Observations:
- Les fichiers Macintosh restent intacts car leurs spécificités sont stockés dans des alternate streams.
- Les fichiers Macintosh du volume qui étaient présents dans la corbeille sont perdus car le répertoire caché Network Trash Folder est effacé quand on supprime un partage Macintosh.
- Le stream
AFP_IdIndex est supprimé quand on supprime un partage Macintosh. Il est recréé au démarrage suivant de SFM. En conséquence,
l'indexation ex nihilo d'un volume Macintosh peut demander beaucoup de temps et consommer de la mémoire non paginée s'il y a beaucoup de fichiers dans le volume ainsi redéfini.
- N'oubliez pas non plus de défragmenter régulièrement les volumes NTFS. Bien que les utilitaires de défragmentation ne tiennent pas compte des alternate streams, ceux-ci ne contiennent pas en général beaucoup de données et la pénalisation induite par leur présence reste faible.
- Vérifiez auprès de votre fournisseur de système de backup que celui-ci copie bien les alternate streams (donc les fichiers Macintosh) et travaille en Unicode (cf. ci-dessous).
2. Les noms de fichiers Macintosh et l'UNICODE
Les noms de fichiers Macintosh et les noms de fichiers NTFS
Tout utilisateur d'un serveur de fichiers Macintosh sur NT a un jour été confronté à un problème de ce type : un client Macintosh a créé un document nommé par exemple Annonce 20/08/00 qui est vu sous le nom Annonce 20|08|00 par les clients NT/2000 et sous le nom Annonce 20?08?00 par les clients 95/98/Me. Ce fichier est inaccessible depuis l'application correspondante sous Windows (NT, 2000 ou 95/98/Me). De plus, l'Explorateur 95/98/Me ne peut accéder à ce fichier alors que l'Explorateur de NT peut le déplacer, le renommer ou l'effacer.
Les noms de fichiers ou de dossiers Macintosh doivent en effet respecter les règles suivantes :
Les noms de fichiers NTFS doivent respecter les règles suivantes :
NTFS utilise le codage UNICODE pour représenter en interne les fichiers Macintosh dont le nom comporte des caractères interdits pour Windows tout en autorisant la manipulation de ces fichiers par les applications NT (lorsqu'elle sont correctement écrites !).
Que ce soit pour un client Windows ou un client Macintosh, NTFS stocke toujours les noms de fichiers ou de dossiers au format UNICODE .
L'UNICODE est une technique de représentation des chaînes de caractères. Chaque caractère est représenté en UNICODE sous la forme de deux octets au lieu d'un seul comme habituellement en ASCII étendu. Les caractères ASCII courants sont suivis d'un octet nul X'00'. Le caractère A (X'41' en ASCII) est ainsi représenté par X'4100' en UNICODE.
Quand un client Macintosh crée un fichier sur un volume SFM, ce nom doit être converti du code ANSI utilisé par le Macintosh vers l'UNICODE utilisé par NTFS. Pour transcoder en UNICODE les caractères autorisés dans un nom de fichier Macintosh mais interdits dans un nom de fichier Windows, SFM utilise la Private Use Area du standard UNICODE selon le tableau suivant :
Macintosh ANSI |
UNICODE |
01-1F |
01F0-1FF0 |
" |
20F0 |
* |
21F0 |
/ |
22F0 |
< |
23F0 |
> |
24F0 |
? |
25F0 |
\ |
26F0 |
| |
27F0 |
Espace à la fin du nom du fichier |
28F0 |
Point à la fin du nom du fichier |
29F0 |
Logo Apple |
2AF0 |
Quand un client Macintosh veut accéder à un fichier stocké par un Macintosh sur NTFS, SFM effectue l'opération de conversion inverse depuis le nom UNICODE ; le client en question voit donc son fichier sous son nom original et avec les caractères spécifiques au Macintosh.
Quand un client Macintosh veut accéder à un fichier stocké par un client Windows sur NTFS, SFM effectue un transcodage des caractères invalides vers des caractères équivalents de telle façon que le client en question voit le fichier avec des caractères corrects pour un Macintosh.
Les applications Windows écrites selon le standard UNICODE voient les fichiers Macintosh avec leur propres caractères définis dans leur propre Private Use Area. Ces applications peuvent donc accéder à tous les fichiers ou dossiers Macintosh sur NTFS. C'est le cas par exemple de l'Explorateur de NT. Par contre, les applications Windows qui sont écrites selon le standard ANSI utilisent une autre correspondance. Les caractères UNICODE de la Private Use Area sont convertis vers le caractère ANSI par défaut : le point d'interrogation (?). Or comme le point d'interrogation est un caractère joker pour les plate-forme Windows, les applications écrites selon le standard ANSI ne peuvent pas accéder à ces fichiers. C'est le cas de toutes les application s'exécutant sur Windows 95/98/Me puisque ce système ne supporte pas l'UNICODE. Les éditeurs de logiciels écrivent peu d'applications véritablement UNICODE ou d'applications mixtes: UNICODE pour NT/2000 et ANSI pour 95/98/Me. Ils écrivent "au plus simple", en ANSI, de façon à ce que la même application tourne indifféremment sur NT/2000 et 95/98/Me ; en conséquence ces applications ne peuvent accéder aux fichiers Macintosh dont les noms comportent les caractères évoqués.
Enfin, si un nom de fichier Windows comporte plus de 31 caractères, SFM présente le fichier en question avec son "nom court" (8+3) aux clients Macintosh.
J'ai écrit
MacNames
, une application NT/2000 permettant de renommer de façon transparente les fichiers Macintosh stockés sur un volume NTFS.
Voici ses principales caractéristiques:
Lorsque son Explorateur lui permet d'afficher les fichiers cachés, un client Windows 95/98/Me voit parfois des fichiers nommés ICON_. Ces fichiers sont de taille nulle et il ne peut pas les renommer, les déplacer ou les effacer. Un Explorateur NT voit ces fichiers cachés sous le nom ICON| et il peut les manipuler.
Ces fichiers sont créés par SFM pour maintenir l'icône d'un dossier lorsqu'elle a été modifiée par un Macintosh. Le code de l'icône est stocké dans l'alternate stream AFP_Resource de ce fichier (et son stream AFP_AfpInfo contient un Type=icon, Creator=MACS). Comme les alternate streams ne peuvent exister sans main streams, SFM crée un fichier caché ICON_ dont le dernier caractère du nom est un caractère UNICODE de la Private Use Area de NT (X'0DF0'). Ce caractère n'est pas converti vers le code ANSI Windows (ni vers le code ANSI Macintosh d'ailleurs) et ces fichiers ne sont donc pas manipulables par un client 95/98/Me ou par un client Macintosh.
Références
Apple :
Inside Macintosh : Files
Microsoft Knowledge Base, Articles:
Q105763
,
Q106663
,
Q117258
,
Q147438
Services for Macintosh - File Services for Macintosh
http://www.microsoft.com-msj-defaulttop.asp-page=-msj-1198-ntfs-ntfstop.htm
http://msdn.microsoft.com/msdn-online/start/features/ntfs5.asp
FAQ : NTFS Services for Macintosh
Windows-MacOS Cooperation List FAQ
par Darryl Lee
La liste Mac-NT
par Dan Schwartz
Frank Heyne :
http://www.heysoft.de/nt/ntfs-ads.htm
March Information Systems :
http://europe.iss.net/streams/
Alert: Virus Scanner inadequacies with NTFS
NTFS file structure for Mac Volumes
Detecting Alternate Data Streams
par David LeBlanc (30 novembre 2000)
I have missing space on my NTFS partitions (Alternate Data Streams)
par John Savill (9 Janvier 2000)
Windows, NTFS and Alternate Data Streams, by Damon Martin
(9 mai 2001)
Le site
MacWindows
de John Rizzo est une mine de renseignements
Les
Signatures Macintosh
par Pierre Duhem
Présentation de
MacExplorer
Présentation de
MacNames
Présentation du logiciel de mirroring et sauvegarde
Idem
Ces programmes sont "mixtes" (Unicode sur NT/2000, ANSI sur 95/98/Me) et opèrent sur des fichiers Windows ou Macintosh sur NT/2000/XP.
Il sont intégralement écrits en Visual Basic - langage pourtant fort peu "orienté système".
Les éditeurs n'ont donc aucune excuse lorsqu'ils proposent des logiciels de quotas faux,
des antivirus déficients, des applications qui ignorent les documents provenant d'une autre plate-forme, etc.
Vous pouvez nous joindre ici
Nous vous invitons également à essayez les autres utilitaires de
Soft Experience
qui facilitent l'intégration des plate formes Windows et Macintosh
MacNames : facilite l'échange de données entre Windows et Macintosh et l'intégration des 2 plate formes connectées à un même serveur Windows NT, Windows 2000 ou Windows XP. Il permet de renommer automatiquement les fichiers Macintosh stockés sur un serveur Windows NT/2000/XP en supprimant les caractères invalides et en ajoutant les extensions aux fichiers de façon à convertir les noms de Mac à PC.
Idem automatise la synchronisation de fichiers et la réplication de répertoires . Il sauvegarde les données sensibles et évolutives en les dupliquant d’un support informatique vers un autre. Facilement paramétrable pour un fonctionnement en mode application ou service Windows il peut être utilisé pour synchroniser des volumes Mac sur Windows NT/2000/XP.
Delenda efface quotidiennement le contenu d'une liste de dossiers ou les transfère vers des dossiers archives, en local ou sur un serveur en fonction de la date de création, modification ou de dernier accès. Très utile dans le pré-presse ou de nombreux textes deviennent rapidement obsolètes.
Catalogue explore les documents MS Office, StarOffice, OpenOffice.org , affiche ou met à jour leurs propriétés (standard ou personnalisées), crée automatiquement des catalogues HTML et exporte les méta données au format XML . Les commentaires de fichiers Macintosh stockés sur des serveurs Windows sont également extraits : http://www.metadataminer.com
Faites connaître ce site à un ami ou partenaire en lui recommandant ce lien !