Los archivos ZIP creados con GUI tienen más bytes que los archivos ZIP creados en un shell

Creé dos archivos ZIP del mismo directorio. Uno con la GUI, el otro con:

$ zip -r alpha_cmd.zip Alpha

El directorio Alpha tiene 33.640 MB con 164 elementos.

El archivo ZIP creado por la GUI es 2.100 bytes más grande que el archivo ZIP creado en la línea de comando.

¿Por qué el archivo ZIP creado con la GUI es más grande?

Nota : Aunque los archivos ZIP tienen diferentes tamaños, cuando se descomprimen, el directorio de cada uno tiene exactamente el mismo número de bytes. Básicamente, desconfío de las posibles inconsistencias introducidas al administrar mi sistema de archivos con la GUI y con los comandos de shell.

file zip

— david
fuente

Uno puede tener archivos invisibles, el otro no?

— Tetsujin

A partir de esta respuesta SU intentaditto -ck --rsrc --sequesterRsrc --keepParent folder folder.zip

— user151019

@ Mark Olvidé responder. Ese comando "ídem" crea exactamente el mismo archivo que Finder. Y los archivos ídem / zip / "Finder ZIP" son multiplataforma. Gracias por tu tiempo y esfuerzo.

— david

Respuestas:

La compresión desde el Finder agrega una carpeta __MACOSX, invisible en Mac, que contiene bifurcaciones de recursos de OS X como iconos personalizados y demás. De Wikipedia :

La bifurcación de recursos es una bifurcación o sección de un archivo en el sistema operativo Apple Mac OS utilizado para almacenar datos estructurados junto con los datos no estructurados almacenados dentro de la bifurcación de datos. Una bifurcación de recursos almacena información en una forma específica, que contiene detalles como mapas de bits de iconos, las formas de las ventanas, las definiciones de los menús y sus contenidos, y el código de la aplicación (código de máquina). Por ejemplo, un archivo de procesamiento de texto podría almacenar su texto en la bifurcación de datos, mientras almacena las imágenes incrustadas en la bifurcación de recursos del mismo archivo. La bifurcación de recursos es utilizada principalmente por ejecutables, pero cada archivo puede tener una bifurcación de recursos.

— empedocle
fuente

Corrección menor: no se trata solo de los tenedores de recursos, es todo tipo de metadatos de archivos que el formato zip no maneja de forma nativa, codificado en formato AppleDouble . Eso incluirá comentarios destacados, etiquetas, indicadores de Finder, datos de cuarentena, etc., así como tenedores de recursos.

— Gordon Davisson

Y me preguntaba cuál era la carpeta "__MACOSX" en la mayoría de las cremalleras ... Cuanto más sepa, ¿eh?

— Ave

Otra referencia que podría iluminar la respuesta: stackoverflow.com/questions/107903/…

— DA Vincent

Incluso aparte de la causa principal en este caso (Finder agrega cosas ocultas adicionales, como dice empedocle), los diferentes tamaños para los ZIP de los mismos datos no indican un problema, cuando la diferencia de tamaño es una fracción de un porcentaje.

Las diferentes implementaciones de ZIP pueden tener un nivel de compresión predeterminado diferente (compensación entre el tiempo de CPU y el tamaño guardado), o simplemente tener un código diferente que guarda más o menos coincidencias, ahorrando más o menos bytes en el nivel de compresión predeterminado.

Por ejemplo, 7-Zip generalmente crea .ziparchivos más pequeños que otros programas ZIP. (Y no, no estoy hablando de su propio .7zformato de archivo. También tiene un mejor compresor ZIP simple).

zipcmp es un programa cmdline que puede comparar archivos ZIP. El valor predeterminado es comparar solo el directorio ZIP, para verificar que todos los archivos tengan el mismo nombre, tamaño y CRC . Si este es el caso, es casi seguro que ambos archivos ZIP tengan el mismo contenido, pero solo se comprimen de manera diferente (si el tamaño comprimido difiere). Siempre que los archivos ZIP no estén dañados, por supuesto. Utilícelo unzip -t foo.zippara probar un archivo ZIP en busca de errores de descompresión, CRC no coincidentes, etc.

— Peter Cordes
fuente

¿No afectarían las carpetas __MACOSX al cálculo de CRC?

— Kent

ZIP almacena un CRC separado del contenido sin comprimir de cada archivo comprimido. (Entonces no, por dos razones: los directorios solo contienen otros archivos, no un bloque de datos propio. Y dos, los CRC almacenados en los metadatos ZIP son para cada archivo por separado). Entonces, todos los archivos que eran iguales entre dos archivos ZIP coincidirían en CRC y tamaño descomprimido.

— Peter Cordes

@PeterCordes El hecho de que diferentes implementaciones ZIP pueden producir diferentes tamaños de archivo es exactamente lo que me llamó la atención. Sabía que el shell ejecutaba "/ usr / bin / zip". Pero como Finder me dio un tamaño de archivo diferente, pensé que Finder usaba un ejecutable completamente diferente (y eso me molestó). Si supiera cómo rootear su raíz y tuviera algo de coraje, como prueba movería "/ usr / bin / zip" a "/ tmp", y luego probaría un zip del Finder (y es mejor que emita un error). ¡Pero tengo trabajo que hacer y no puedo arriesgarme a desestabilizar mi Mac!

— david

La forma más segura de reemplazar temporalmente /usr/bin/zipcon una versión diferente sería ln /usr/bin/zip /usr/bin/zip.standard; mv new_zip /usr/bin/zip. De esa manera, siempre tiene un /usr/bin/zip, porque reemplaza atómicamente la implementación del sistema. Además, la versión anterior simplemente se renombra, no se mueve a /tmp(que posiblemente esté en un sistema de archivos diferente). Para deshabilitarla, simplemente cambiaría el nombre a zip.disab, vería si Finder se rompe y luego cambiaría el nombre. Pero las funciones de la biblioteca de creación de zip son comunes. El buscador casi seguro no bifurca / exec /usr/bin/zip.

— Peter Cordes

@PeterCordes Lo entiendo sobre llamar a bibliotecas en lugar del ejecutable. Pero, el ejecutable habría sido "/ usr / bin / ditto", y no "/ usr / bin / zip" de todos modos. La asistencia de este foro es excelente. Gracias por tu tiempo y esfuerzo.

— david