¿Los archivos ZIP conservan todas las funciones de HFS + cuando se crean con el comando Compress del Finder?

Navega tus respuestas
0

¿Es una buena idea hacer una copia de seguridad de un directorio en un sistema de archivos HFS + usando la función Comprimir del buscador, y luego copiar el archivo ZIP en un disco duro FAT32, o en Dropbox, etc.? ¿O podría causar la corrupción de datos o la pérdida de datos?

Por ejemplo, si comprimo mi biblioteca de iTunes y los enlaces simbólicos son reemplazados por otra copia del archivo, eso es un cambio en la semántica. Si mi disco duro falla y yo restauro una copia de la biblioteca de iTunes desde la copia de seguridad, es posible que iTunes no funcione correctamente debido a esto. Por ejemplo, cambiar el contenido de un archivo no afectará al otro. Eliminar el archivo al que se apunta significa que ya no puede leer el contenido de ese archivo a través del enlace simbólico, lo que nuevamente es diferente si el enlace simbólico se reemplaza por una copia de ese archivo. iTunes puede bloquearse debido a una biblioteca dañada o a la biblioteca, lo que significa que la copia de seguridad no cumplió su propósito.

¿Se garantiza que todos los directorios válidos se comprimen a ZIP sin errores y se expanden a una copia idéntica del directorio original, sin pérdida de información o cambios semánticos? Más específicamente, ¿los archivos ZIP son compatibles con todas las funciones de HFS +?

  1. enlaces simbólicos
  2. Enlaces físicos (incluidos los directorios, que son compatibles con HFS +)
  3. Alias
  4. Atributos extendidos
  5. Horquillas de recursos
  6. ACL
  7. permisos de Unix
  8. Todos los nombres de ruta válidos en HFS +. En otras palabras, ¿ZIP admite todos los caracteres que son válidos para usar en un nombre de ruta? ¿Es compatible ZIP con el nombre de ruta más largo que puede crear en HFS +, o existe un límite de longitud de ruta inferior en el formato ZIP?
  9. ¿Hay un límite de tamaño de archivo de 4GB?

... y así sucesivamente.

Me preocupa la posibilidad de cambios silenciosos, que causan la pérdida silenciosa de datos o la corrupción sin que yo lo sepa hasta que sea demasiado tarde.

Esta es una pregunta sobre el formato ZIP y también sobre el comando Compress del Finder. Porque incluso si el formato ZIP admite algo, si la implementación del Finder no lo hace, no ayuda.

    
pregunta Vaddadi Kartick 13.08.2014 - 09:08

1 respuesta

1

No hay crédito para mí. Literalmente, tomé esto del usuario NSGod : enlace

Mi propia adición, un poco obvia:

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

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

¿Qué sistema operativo es el equipo 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 simple con información adicional de "Mac" que le permite a OS X saber que debe tratar el archivo como un enlace simbólico. Esta información adicional de Mac es un tipo de archivo especial, código de creador e información de marca del Finder, que no se almacena en el archivo en sí, sino en el directorio del disco HFS +.

En OS X, cuando crea un archivo .zip, no hay espacio en el flujo zip para esta información adicional de Mac, por lo que, en cierto sentido, el enlace simbólico se almacena dentro del archivo zip como un archivo simple. Si alguien en otra Mac puede descomprimir el archivo y representarlo correctamente, la estructura original parece depender de quién o qué usas para descomprimirlo.

Por ejemplo, hace aproximadamente un mes 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 biblioteca Cg de NVIDIA en forma de marco, que utiliza internamente enlaces simbólicos. Originalmente hubo un problema con Steam que no restauró correctamente la información Mac necesaria en Trine.app como se menciona en este hilo: enlace

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

Observequetodosloselementoscoinciden,peroloquedeberíanserenlacessimbólicossonarchivosdedatossimples.

DespuésdeanalizardetenidamenteelregistroFSCatalogInfodeamboselementos,mequedóclarocuáleraelproblema:

En la imagen superior notará que el comienzo 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 noveno byte, 0x80, corresponde al indicador kIsAlias del finderInfo.finderFlags . Ese valor se define en /System/Library/Frameworks/CoreServices.framework/.../CarbonCore.framework/.../Headers/Finder.h: 

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

Parece que la función de descompresión integrada en OS X (Utilidad de archivo) está codificada para buscar posibles archivos en el archivo que se está descomprimiendo y que representan enlaces simbólicos, y para establecer la información de manera adecuada. Creo que /usr/bin/ditto (cuando se usa por su capacidad para archivar archivos) también se encarga de esto por usted. No estoy seguro de si zip o unzip lo hacen.

    
respondido por el CousinCocaine 13.08.2014 - 09:42

Lea otras preguntas en las etiquetas

2012 MacBook Air tiene un punto de desgaste en la parte inferior izquierda Apple El informe de errores se apagó de repente. OSX 10.9.4