Convertire TAR in GZ

I TAR semplici sono più rari di quelli gzippati e compaiono in luoghi riconoscibili. docker save ne scrive uno. Gli script di backup a cui è stato detto di raggruppare ma non comprimere ne scrivono uno. Alcuni flussi NAS e nastro ne producono uno perché la compressione avviene altrove nella catena.

Il risultato è un archivio grande all’incirca quanto la somma di tutto il suo contenuto più una sorprendente quantità di sovraccarico. Va bene su un disco locale ed è costoso ovunque altro: su un caricamento con connessione lenta, in un bucket che addebita per gigabyte-mese, in un limite di allegato email, in una cache CI recuperata a ogni build.

La struttura del TAR è del 1979 ed è deliziosamente semplice: un’intestazione di 512 byte che descrive un file, poi il file stesso riempito fino al prossimo confine di 512 byte, poi la prossima intestazione, e due blocchi di zeri alla fine per segnare la conclusione. Niente viene compresso e niente viene indicizzato.

Il costo si vede sui file piccoli. Un file di un byte occupa 1.024 byte in un TAR — un intero blocco intestazione e un intero blocco dati. Diecimila file di configurazione, sorgente o documenti JSON che mediano poche centinaia di byte ciascuno portano diversi megabyte di intestazioni e riempimento che non contengono alcuna informazione. Gzip è estremamente bravo esattamente in questo.

Gzip usa DEFLATE con una finestra cronologica di 32 KB, il numero che decide tutto in questa conversione. Dentro qualsiasi tratto di 32 KB trova stringhe ripetute e le sostituisce con riferimenti, poi codifica Huffman ciò che resta. Su prosa, codice, log, XML, JSON e configurazione è un risparmio grande e affidabile.

Ciò che gli sfugge è la ripetizione a lungo raggio. Se la stessa intestazione di licenza appare in duecento file sparsi in un tarball da 40 MB, gzip la comprime duecento volte separatamente perché non può mai vederne due insieme. È il divario che XZ e 7Z esistono per colmare.

Vale la pena dirlo apertamente perché sorprende chi si aspetta che un involucro venga applicato attorno al proprio file esistente. La conversione spacchetta il TAR caricato, poi scrive un nuovo TAR dai contenuti estratti e lo comprime con gzip. I file dentro sono identici byte per byte; il tarball attorno a loro è nuovo.

Ne conseguono due cose. Primo, un checksum pubblicato contro il TAR originale non corrisponderà a nulla qui, perché non state più tenendo il TAR originale. Secondo, ciò che il vecchio contenitore registrava sui suoi membri può cambiare: permessi e timestamp sono i campi a rischio.

Un flusso gzip ha un campo intestazione per il nome del file originale, motivo per cui gunzip backup.gz su una macchina Unix può produrre un file chiamato backup.tar anche se niente nel comando lo diceva. È una piccola cortesia che il formato estende ed è perché un file gzippato è leggermente meno anonimo di uno xz o bzip2, che non memorizzano alcun nome.

Non fateci affidamento per nulla di importante. Molti strumenti scrivono un nome generico in quel campo, molti altri lo ignorano all’estrazione, e un file trasferito attraverso un sistema che riscrive gli archivi lo perde interamente. L’estensione che date al download è l’etichetta che verrà davvero letta.

Un flusso gzip viene decodificato dall’inizio alla fine con una finestra fissa di 32 KB e nessun indice, il che sembra una limitazione ed è la fonte del suo vantaggio più grande. Significa che l’archivio può essere consumato mentre arriva: curl https://… | tar xzf - spacchetta un download che non tocca mai il disco.

Il registro segnala questo sul formato stesso, ed è la ragione per cui gzip non è stato spodestato da niente di più forte in vent’anni di tentativi. I formati con un grande dizionario hanno bisogno di memoria proporzionale a esso; i formati con un indice centrale hanno bisogno della fine del file prima di poter elencare l’inizio.

I tre non sono classificati; stanno in punti diversi della stessa curva. Gzip è il più veloce a comprimere e decomprimere e dà il risparmio più piccolo. XZ dà di gran lunga il risparmio maggiore su testo, a un grande costo in tempo di compressione e nella memoria necessaria per spacchettarlo. BZ2 sta fra loro nel rapporto, è lento da decomprimere, ed è segnato legacy.

Decidete in base a cosa succede al file dopo. Qualcosa che verrà recuperato e spacchettato ripetutamente, da macchine che non controllate, su una pipe — gzip. Qualcosa che starà in archiviazione fredda per anni e verrà letto quasi mai — XZ.

Non nel vostro browser. La maggior parte degli strumenti qui gira sul vostro dispositivo e lo dice; il riimpacchettamento di archivi è una delle eccezioni, perché richiede 7-Zip e gzip come programmi veri. Il file viaggia su una connessione cifrata verso un container che li esegue e non ha accesso internet in uscita.

Ogni lavoro riceve una cartella temporanea su un filesystem in memoria cancellata quando il lavoro finisce qualunque sia l’esito, e tutto ciò che è ancora in esecuzione dopo sessanta secondi viene terminato. Il livello gratuito accetta 25 MB per file caricato, ed è la coppia dove quel limite morde di più.

tar xzf archive.tar.gz gestisce entrambi i livelli in un unico passaggio su macOS, Linux e i BSD, e Windows moderno include un tar che fa lo stesso da PowerShell. Gli archiviatori grafici su Windows tipicamente disfano il livello gzip e vi lasciano un .tar da aprire di nuovo.

Prima che l’originale sparisca, confrontate l’elenco: tar tzf sul risultato contro tar tf sulla sorgente, stesso conteggio e stessi percorsi. Il livello superiore è ciò da guardare, perché un archivio impacchettato dall’interno di una cartella e uno impacchettato dalla cartella madre differiscono per una cartella iniziale su ogni voce.