I file ZIP creati con la GUI hanno più byte dei file ZIP creati in una shell

Ho creato due file ZIP della stessa directory. Uno con la GUI, l'altro con:

$ zip -r alpha_cmd.zip Alpha

La directory Alpha è 33.640 MB con 164 elementi.

Il file ZIP creato dalla GUI è maggiore di 2.100 byte rispetto al file ZIP creato nella riga di comando.

Perché il file ZIP creato con la GUI è più grande?

Nota : anche se i file ZIP hanno dimensioni diverse, quando decompressi, ciascuna directory ha lo stesso numero esatto di byte. Fondamentalmente, sono molto diffidente nei confronti di possibili incoerenze introdotte gestendo il mio file system con la GUI e con i comandi della shell.

file zip

— david
fonte

Uno potrebbe avere file invisibili, l'altro no?

— Tetsujin,

Da questa risposta SU provaditto -ck --rsrc --sequesterRsrc --keepParent folder folder.zip

— user151019

@Mark Ho dimenticato di rispondere. Quel comando "idem" crea esattamente lo stesso file del Finder. E i file idem / zip / "Finder ZIP" sono tutti multipiattaforma. Grazie per il tuo tempo e sforzo.

— David,

Risposte:

Lo zipping dal Finder aggiunge una cartella __MACOSX, invisibile sui Mac, che contiene fork di risorse OS X come icone personalizzate e simili. Da Wikipedia :

Il fork delle risorse è un fork o una sezione di un file sul sistema operativo Apple Mac OS utilizzato per archiviare i dati strutturati insieme ai dati non strutturati memorizzati nel fork dei dati. Un fork di risorse memorizza le informazioni in un formato specifico, contenente dettagli come bitmap di icone, forme di finestre, definizioni di menu e relativi contenuti e codice dell'applicazione (codice macchina). Ad esempio, un file di elaborazione testi può archiviare il suo testo nel fork dei dati, mentre memorizza qualsiasi immagine incorporata nel fork delle risorse dello stesso file. Il fork delle risorse viene utilizzato principalmente dagli eseguibili, ma ogni file è in grado di avere un fork delle risorse.

— empedocle
fonte

Correzione minore: non sono solo i fork di risorse, sono tutti i tipi di metadati di file che il formato zip non gestisce in modo nativo, codificato in formato AppleDouble . Ciò includerà commenti, tag, flag del Finder, dati di quarantena, ecc., Nonché fork di risorse.

— Gordon Davisson,

E mi chiedevo quale fosse la cartella "__MACOSX" nella maggior parte delle zip ... Più sai, eh?

— Ave,

Un altro riferimento che potrebbe illuminare la risposta: stackoverflow.com/questions/107903/…

— DA Vincent

Anche a parte la causa principale in questo caso (Finder che aggiunge elementi nascosti extra, come dice empedocle), dimensioni diverse per i ZIP degli stessi dati non indicano un problema, quando la differenza di dimensioni è una frazione di una percentuale.

Diverse implementazioni ZIP potrebbero avere un diverso livello di compressione predefinito (compromesso tra tempo della CPU e dimensioni salvate) o semplicemente avere un codice diverso che salva più o meno corrispondenze, risparmiando più o meno byte al livello di compressione predefinito.

Ad esempio, 7-Zip di solito crea .zipfile più piccoli rispetto ad altri programmi ZIP. (E no, non sto parlando del suo .7zformato di file. Ha anche un compressore ZIP semplice.)

zipcmp è un programma cmdline in grado di confrontare i file ZIP. L'impostazione predefinita è il confronto solo della directory ZIP, per verificare che tutti i file abbiano lo stesso nome, dimensione e CRC . In questo caso, entrambi i file ZIP hanno quasi lo stesso contenuto, ma sono compressi in modo diverso (se la dimensione compressa è diversa). Fintanto che i file ZIP non sono danneggiati, ovviamente. Utilizzare unzip -t foo.zipper testare un file ZIP per errori di decompressione, CRC non corrispondenti, ecc.

— Peter Cordes
fonte

Le cartelle __MACOSX non influirebbero sul calcolo CRC?

— Kent,

ZIP memorizza un CRC separato i contenuti non compressi di ciascun file compresso. (Quindi no, per due motivi: le directory contengono solo altri file, non un blocco di dati propri. E due, i CRC memorizzati nei metadati ZIP sono per ciascun file separatamente.) Quindi tutti i file che erano uguali tra due file ZIP corrisponderebbero in CRC e dimensioni decompresse.

— Peter Cordes,

@PeterCordes Il fatto che diverse implementazioni ZIP possano produrre file di dimensioni diverse è esattamente ciò che ha attirato la mia attenzione. Sapevo che la shell eseguiva "/ usr / bin / zip". Ma poiché Finder mi ha dato una dimensione del file diversa, ho pensato che Finder usasse un eseguibile completamente diverso (e questo mi ha sconvolto). Se sapessi come eseguire il root e avessi un po 'di coraggio, come test sposterei "/ usr / bin / zip" su "/ tmp", quindi proverei uno zip Finder (e sarebbe meglio emettere un errore). Ma ho del lavoro da fare e non posso rischiare di destabilizzare il mio Mac!

— David,

Il modo più sicuro per sostituire temporaneamente /usr/bin/zipcon una versione diversa sarebbe ln /usr/bin/zip /usr/bin/zip.standard; mv new_zip /usr/bin/zip. In questo modo, hai sempre un /usr/bin/zip, perché sostituisci atomicamente l'implementazione del sistema. Inoltre, la vecchia versione è appena stata rinominata, non spostata in /tmp(che potrebbe essere su un diverso filesystem). Per disabilitarlo, lo rinominerei semplicemente zip.disab, vedrei se il Finder si rompe, quindi lo rinominerei. Ma le funzioni della libreria di creazione zip sono comuni. Il Finder quasi sicuramente non fork / exec /usr/bin/zip.

— Peter Cordes,

@PeterCordes Ho capito come chiamare le librerie anziché l'eseguibile. Ma l'eseguibile sarebbe stato "/ usr / bin / ditto", e non comunque "/ usr / bin / zip". L'assistenza da questo forum è eccezionale. Grazie per il tuo tempo e sforzo.

— David,