XZ naar ZIP omzetten

XZ is gewoon wat upstream publiceert. Broncode-releases, distributiepakketten en hele taaltoolchains verschijnen overwegend als .tar.xz, want het bestand wordt duizenden keren opgehaald en eenmaal gebouwd, en elke bespaarde megabyte is een megabyte herhaaldelijk bespaard.

Die conventie is ontstaan voor mensen met een shell, waar tar -xJf beide lagen in één opdracht uitpakt. Buiten dat pad is het onhandig: Windows toont een onbekend bestandstype, macOS biedt niets bruikbaars, en de download blijft in een map liggen als vier megabyte iets.

XZ comprimeert één stroom en verder niets. In ons register is het een streamformaat met één lid, en de afwezigheid van elke mapstructuur staat genoemd als bekend probleem — een .xz-bestand heeft geen veld voor een naam, een pad of een rechtenbit.

De namen leven in de TAR eronder: een kopblok per bestand, de inhoud in volgorde, geen eigen compressie en geen index. Je map terugkrijgen betekent dus twee aparte dingen ongedaan maken, en alleen het eerste doen laat je met een .tar die op Windows net zo min opent als het bestand waar je mee begon.

LZMA2 codeert een herhaling als een verwijzing naar iets tot 64 MB eerder in de stroom, en het codeert die verwijzingen met een range-coder die minder bits kost dan DEFLATE’s Huffman-codes. Tegenover ZIP’s venster van 32 KB is dat ruwweg tweeduizend keer het bereik.

Op een broncodeboom is het effect dramatisch, want de herhaling zit overal en is verspreid: dezelfde licentiekop die tweehonderd bestanden opent, dezelfde importregels, dezelfde gegenereerde boilerplate. Dat is waarom een release-tarball zo vaak een klein deel is van waar hij naar uitpakt.

Voordat er iets uitgepakt wordt, wordt het archief gevraagd wat het claimt te bevatten, en een opgegeven totaal boven 2 GB wordt geweigerd met een duidelijke melding. Bij de meeste archiefparen bestaat die grens voor bewust kwaadaardige bestanden en gaat ze bij een echt bestand vrijwel nooit af.

Dit paar is de uitzondering. Een sterke compressor toegepast op een grote boom kan ruim 2 GB aan inhoud in een klein genoeg bestand stoppen om comfortabel te uploaden, dus een gewoon, volkomen eerlijk broncodearchief kan geweigerd worden.

Een hoop, relatief gezien. ZIP comprimeert elk item onafhankelijk tegen een venster van 32 KB en schrijft er een directory bij, dus het kan helemaal niet over bestandsgrenzen heen kijken, laat staan 64 MB terug. Alles wat het lange woordenboek vond wordt opnieuw betaald.

Voor iemand die in een release wil kijken is dat een eerlijke ruil — de ZIP opent zonder software. Voor iets dat opgeslagen of doorgestuurd wordt is het een slechte ruil, en het betere antwoord is de .tar.xz precies te bewaren zoals upstream publiceerde.

LZMA2 decomprimeren betekent het woordenboek waarmee het bestand gepakt is in geheugen houden, dus het benodigde geheugen volgt die instelling in plaats van de grootte van het gecomprimeerde bestand. Een kleine .xz geschreven met een groot woordenboek is veeleisender om uit te pakken dan de grootte doet vermoeden.

Op elke laptop of server is dit onopvallend. Het wordt echt op beperkte hardware — een router, een klein embedded board, een geheugenbeperkte build-agent.

Niet elk xz-bestand is een tarball. Eén gecomprimeerde schijfkopie, één groot logbestand, één databasedump — xz toegepast op één bestand is het formaat exact zoals ontworpen, zonder TAR erin.

De omzetter leest wat er uit de xz-laag komt en probeert het als TAR te lezen; lukt dat niet, dan wordt de inhoud behandeld als het ene bestand dat het is en bevat de ZIP dat.

Deze omzetting gebeurt op onze server, niet in de pagina. Het bestand wordt over een versleutelde verbinding geüpload, gedecomprimeerd, uitgepakt, opnieuw verpakt als ZIP vanuit de uitgepakte map en teruggestuurd, en de upload, de tussenliggende tar en de uitvoer worden allemaal verwijderd zodra de taak eindigt.

De werkruimte is geheugengebaseerd en begrensd. Gratis uploads stoppen bij 25 MB, elke taak wordt na zestig seconden gedood, en met wachtwoord beveiligde archieven falen met een melding in plaats van te wachten op een prompt.

Gaat het archief naar een Linux-machine, een build-agent of een containerimage, dan is omzetten een stap achteruit op elke as: het doel heeft xz al geïnstalleerd, de ZIP is aanzienlijk groter, en de rechten die de TAR droeg overleven de reis naar een ZIP niet.

Zet om wanneer iemand op een desktop moet kijken, wanneer een uploadformulier op ZIP staat, of wanneer je inhoud doorstuurt naar iemand die nooit een archiveerder installeert. Komen .tar.xz-bestanden regelmatig binnen, dan doen 7-Zip en Keka beide lagen lokaal zonder groottegrens.

Broncode-releases worden meestal gepubliceerd met een checksumbestand en vaak met een losse handtekening, en beide beschrijven de .tar.xz precies zoals upstream hem schreef. Verifieer tegen de oorspronkelijke download voordat je iets omzet, want een herpakte ZIP zal met geen van beide overeenkomen.

Dat is geen gebrek van de omzetting; het is waar verificatie voor dient. De juiste volgorde is de handtekening controleren op het opgehaalde bestand, jezelf ervan overtuigen dat het van het project komt, en dan pas herpakken voor wat een ZIP nodig heeft.