¿Los archivos ZIP conservan todas las características de HFS+ cuando se crean con el comando Compress de Finder?

No hay crédito para mí. He tomado esto literalmente del usuario NSGod : https://superuser.com/a/222590

Mi propia adición, un poco obvia:

• el sistema de archivos de destino debe admitir enlaces simbólicos, enlaces duros, etc., de lo contrario no funcionará
• puede utilizar el zip en la línea de comandos y preservar estos tipos de archivo manualmente con zip --symlinks -r foo.zip foo/

¿Cómo estás creando el archivo .zip en OS X? (Usando una herramienta de línea de comandos, y si es así, cuál, o usando Archive Utility, etc.)

¿Qué sistema operativo está ejecutando el ordenador de destino (donde se descomprimirá el archivo) y qué método está utilizando para descomprimir el archivo allí?

En primer lugar, en OS X, los enlaces simbólicos son básicamente archivos de texto plano con alguna información "Mac" adicional que permite a OS X saber que debe tratar el archivo como un enlace simbólico. Esta información extra de Mac es un tipo de archivo especial, un código de creador y la información de la bandera del Finder, que se almacena no en el archivo en sí, sino en el directorio del disco HFS+.

En OS X, cuando se crea un archivo .zip, no hay espacio en el flujo del zip para esta información extra de Mac, así que, en cierto sentido, el enlace simbólico se almacena dentro del archivo zip como un archivo simple. Que alguien en otro Mac pueda descomprimir el archivo y que éste represente adecuadamente la estructura original parece depender de quién o qué utilice para descomprimirlo.

Por ejemplo, hace un mes más o menos una empresa lanzó un juego a través de Steam, el software de distribución de juegos de Valve. El paquete de aplicaciones del juego incluía la librería Cg de NVIDIA en forma de framework, que internamente utiliza enlaces simbólicos. Originalmente hubo un problema con Steam que no restauraba correctamente la información necesaria de Mac en Trine.app como se menciona en este hilo: http://forums.steampowered.com/forums/showthread.php?t=1556083

La imagen de abajo muestra 2 copias diferentes del Cg.framework, una que había instalado por separado desde el sitio web de NVIDIA (imagen superior), y la imagen inferior muestra lo que se recibió con el juego:

Observe que todos los elementos coinciden, pero lo que deberían ser enlaces simbólicos son archivos de datos simples.

Después de mirar con detenimiento el registro FSCatalogInfo de ambos artículos, me quedó claro cuál era el problema:

Notarás en la imagen superior que el principio de la estructura finderInfo tiene los siguientes valores:

0x736C6E6B = 'slnk'
0x72686170 = 'rhap'

Estos valores se definen en /usr/include/hfs/hfs_format.h:

/*
 *  File type and creator for symbolic links
*/
enum {
    kSymLinkFileType  = 0x736C6E6B, /* 'slnk' */
    kSymLinkCreator   = 0x72686170  /* 'rhap' */
};

El valor del 9º byte, 0x80, corresponde al kIsAlias bandera del finderInfo.finderFlags . Ese valor está definido en /System/Library/Frameworks/CoreServices.framework/.../CarbonCore.framework/.../Headers/Finder.h:

enum {
    kIsAlias                      = 0x8000 /* Files only */
};

Parece que la función de descompresión incorporada a OS X (Archive Utility) está programada para buscar posibles archivos en el archivo que se está descomprimiendo que representen enlaces simbólicos, y para establecer la información de manera apropiada. Creo que /usr/bin/ditto (cuando se utiliza por su capacidad de archivar ficheros) también se encarga de esto por ti. No estoy seguro de si zip o unzip hacer.