Quelques questions : 1) La structure de dossiers que vous archivez utilise-t-elle des liens symboliques en interne pour gagner de l'espace ? (Par "en interne", je veux dire, étant donné un dossier racine particulier, est-ce que les liens symboliques au sein de ce dossier racine font uniquement référence à d'autres fichiers ou répertoires qui se trouvent également dans ce dossier).
2) Comment créez-vous l'archive .zip sous OS X ? (En utilisant un outil de ligne de commande, et si oui, lequel, ou en utilisant Archive Utility, etc.)
3) Quel est le système d'exploitation de l'ordinateur cible (où l'archive sera décompressée) et quelle méthode utilisez-vous pour décompresser le fichier ?
Tout d'abord, dans OS X, les liens symboliques sont essentiellement des fichiers de texte brut avec quelques informations "Mac" supplémentaires qui permettent à OS X de savoir qu'il doit traiter le fichier comme un lien symbolique. Ces informations Mac supplémentaires sont un type de fichier spécial, un code créateur et des informations sur l'indicateur Finder, qui sont stockés non pas dans le fichier lui-même, mais dans le répertoire du disque HFS+.
Dans OS X, lorsque vous créez un fichier .zip, il n'y a pas de place dans le flux zip pour ces informations Mac supplémentaires, donc, dans un sens, le lien symbolique est stocké dans le fichier zip comme un simple fichier. Le fait que quelqu'un sur un autre Mac puisse décompresser l'archive et qu'elle représente correctement la structure originale semble dépendre de la personne ou du matériel utilisé pour la décompresser.
Par exemple, il y a environ un mois, une entreprise a sorti un jeu sur Steam, le logiciel de distribution de jeux de Valve. Le paquet d'applications du jeu comprenait la bibliothèque Cg de NVIDIA sous la forme d'un framework, qui utilise en interne des liens symboliques. Il y avait à l'origine un problème avec Steam qui ne restaurait pas correctement les informations Mac nécessaires sur Trine.app, comme mentionné dans ce fil de discussion : http://forums.steampowered.com/forums/showthread.php?t=1556083
L'image ci-dessous montre 2 copies différentes du Cg.framework, une que j'ai installée séparément depuis le site de NVIDIA (image du haut), et l'image du bas montre ce qui a été reçu avec le jeu :
![alt text]()
Remarquez que tous les éléments correspondent, mais ce qui devrait être des liens symboliques sont des fichiers de données ordinaires.
Après avoir examiné de plus près l'enregistrement FSCatalogInfo des deux articles, j'ai compris quel était le problème :
![alt text]()
Vous remarquerez dans l'image du haut que le début de la structure finderInfo a les valeurs suivantes :
0x736C6E6B = 'slnk'
0x72686170 = 'rhap'
Ces valeurs sont définies dans /usr/include/hfs/hfs_format.h :
/*
* File type and creator for symbolic links
*/
enum {
kSymLinkFileType = 0x736C6E6B, /* 'slnk' */
kSymLinkCreator = 0x72686170 /* 'rhap' */
};
La valeur du 9e octet, 0x80, correspond à la valeur de l'octet de l'adresse de l'utilisateur. kIsAlias du drapeau de l finderInfo.finderFlags . Cette valeur est définie dans /System/Library/Frameworks/CoreServices.framework/.../CarbonCore.framework/.../Headers/Finder.h :
enum {
kIsAlias = 0x8000 /* Files only */
};
Il semble que la fonction de dézippage intégrée à OS X (Archive Utility) soit codée en dur pour rechercher les éventuels fichiers de l'archive en cours de dézippage qui représentent des liens symboliques, et pour définir les informations en conséquence. Je pense que /usr/bin/ditto (lorsqu'il est utilisé pour sa capacité à archiver des fichiers) s'en charge également pour vous. Je ne suis pas sûr que zip o unzip faire.
