Les fichiers ZIP conservent-ils toutes les caractéristiques de HFS+, lorsqu'ils sont créés à l'aide de la commande Compress du Finder ?

Aucun crédit pour moi. J'ai littéralement pris ceci de l'utilisateur NSGod : https://superuser.com/a/222590

Mon propre ajout, un peu évident :

• le système de fichiers cible doit supporter les liens symboliques, les liens durs, etc., sinon cela ne fonctionnera pas
• vous pouvez utiliser le zip dans la ligne de commande et préserver ces types de fichiers manuellement avec zip --symlinks -r foo.zip foo/

Comment créez-vous l'archive .zip sous OS X ? (En utilisant un outil en ligne de commande, et si oui, lequel, ou en utilisant Archive Utility, etc.)

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 fichier ordinaire. 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 :

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 :

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 9ème 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'occupe également de cela pour vous. Je ne suis pas sûr que zip o unzip faire.