Convertir TAR a GZ

Los TAR planos son menos frecuentes que los comprimidos y aparecen en sitios reconocibles. El panel de un alojamiento compartido genera uno al preparar una copia de seguridad para descargar. Un script de respaldo que recibió la orden de empaquetar pero no la de comprimir escribe otro. Algunos flujos de NAS y de cinta los producen porque la compresión ocurre en otro punto de la cadena. Y hay quien escribe uno sin querer, porque las dos órdenes habituales se diferencian en una sola letra y solo una de ellas hace el archivo más pequeño.

El resultado es un archivo que pesa aproximadamente la suma de todo lo que lleva dentro más una cantidad de relleno sorprendente. En un disco local da igual y en cualquier otro sitio sale caro: en una subida por una línea lenta, en un almacenamiento que cobra por gigabyte y mes, en un límite de adjunto, en una caché que se descarga en cada compilación. Es de las pocas conversiones de este sitio donde la respuesta es casi siempre que sí, porque no hay ningún coste de compatibilidad: un tarball comprimido se entiende en más sitios que uno pelado.

La estructura de TAR es de 1979 y es encantadoramente simple: una cabecera de 512 bytes que describe un archivo, después el archivo rellenado hasta el siguiente múltiplo de 512, después la cabecera siguiente, y dos bloques de ceros al final para marcar el cierre. No se comprime nada y no se indexa nada. El formato se diseñó para unidades de cinta, donde los bloques de tamaño fijo eran justamente la idea.

El coste de eso se nota con archivos pequeños. Un archivo de un solo byte ocupa 1.024 bytes dentro de un TAR: una cabecera entera y un bloque de datos entero. Diez mil ficheros de configuración, de código o de texto de unos cientos de bytes cada uno arrastran varios megabytes de cabeceras y relleno que no contienen nada. Y gzip es extraordinariamente bueno precisamente en eso: las tiradas largas de ceros se reducen a casi nada, así que buena parte del ahorro en un archivo de muchos ficheros pequeños viene de retirar estructura y no de comprimir contenido.

Gzip usa DEFLATE con una ventana de historial de 32 KB, y ese número decide todo lo demás. Dentro de cualquier tramo de 32 KB localiza cadenas repetidas y las sustituye por referencias, y después codifica lo que queda con un árbol de frecuencias. Sobre prosa, código, registros, XML, JSON y configuración eso es un ahorro grande y fiable.

Lo que se le escapa es la repetición a larga distancia. Si la misma cabecera de licencia aparece en doscientos archivos repartidos por un tarball de 40 MB, gzip la comprime doscientas veces por separado, porque nunca llega a ver dos a la vez. Esa es la brecha que existen para cerrar XZ y 7Z, y el motivo por el que ganan con holgura en archivos con muchos ficheros parecidos. La respuesta de gzip es que es rápido, que se puede leer en flujo y que está instalado absolutamente en todas partes, que para un archivo que se mueve más de lo que se guarda suele ser el mejor trato.

Conviene decirlo claro, porque sorprende a quien espera que se le ponga una capa alrededor de su archivo. La conversión desempaqueta el TAR que subes, escribe un TAR nuevo a partir del contenido extraído y comprime ese con gzip. Los ficheros de dentro son idénticos byte a byte; el tarball que los rodea es otro.

De ahí salen dos consecuencias. La primera: una suma de verificación publicada contra el TAR original no va a coincidir con nada de lo que descargues, porque ya no tienes aquel TAR. Si hay un resumen que tiene que cuadrar, comprime el archivo con gzip en tu propia máquina, que deja el tarball intacto. La segunda: lo que el contenedor anotaba sobre sus miembros puede cambiar. El aviso de este sitio para los pares de archivos comprimidos lo dice tal cual: los ficheros salen byte por byte, y lo que no sobrevive es lo que el contenedor sabía sobre ellos y no lo que llevaban dentro, empezando por una contraseña y, según el formato, por los permisos y las fechas. Para un paquete de código o un archivo documental da igual; para un artefacto de despliegue, no.

Este par se ejecuta en nuestro servidor, así que el límite gratuito es de 25 MB por archivo y no los 100 que se aplican a lo que ocurre dentro del navegador. Y como un TAR no está comprimido, 25 MB de TAR son 25 MB de contenido real, donde 25 MB de 7Z podrían ser diez veces más.

Hay además un detalle incómodo que es mejor contar: la zona donde se sueltan los archivos aplica el límite del navegador a todo, sin comprobar si el par se ejecuta en el servidor. Es decir, un TAR de 60 MB lo acepta la interfaz y lo rechaza la API por tamaño después de subirlo. Mira el peso antes de empezar y ahórrate la subida.

La copia de seguridad de un alojamiento compartido casi nunca cabe en 25 MB, y esa es una razón perfectamente buena para no usar esta herramienta. Si el TAR viene de descargar un respaldo, comprímelo donde está: una sola orden en cualquier terminal de macOS, Linux o BSD lo resuelve, y el Windows actual trae también una utilidad equivalente que hace lo mismo desde la consola.

Esta página es útil en el caso contrario: un TAR modesto, en un ordenador donde no tienes ni terminal ni permiso para instalar nada, en un equipo prestado o en el trabajo. Decir en qué situación no compensa es más útil que fingir que compensa siempre, y en este par la frontera es muy fácil de ver porque es un número.

Reempaquetar archivos comprimidos necesita 7-Zip y gzip como programas de verdad, así que este par no ocurre en tu navegador. El archivo viaja por una conexión cifrada hasta un contenedor que los ejecuta y que no tiene salida a internet propia. De las 528 conversiones activas de este sitio, 439 no salen del navegador y 89 funcionan así; esta es una de esas 89, y decirlo es la mitad del trato.

La otra mitad es qué le pasa allí. Cada trabajo recibe un directorio temporal recién creado y el archivo se guarda con un nombre fijo, de modo que el nombre que tú le pusiste no llega a escribirse en disco. Ese directorio se borra al terminar dentro de un bloque que se ejecuta también en todas las rutas de error. El resultado se devuelve con la cabecera que impide guardarlo en caché, y en el despliegue no hay ni almacén de objetos ni base de datos: solo el contenedor y un contador de cuota que guarda un único registro con el día y el número de usos.

El plazo se aplica a cada programa que se lanza, no a la petición completa, y una conversión de archivos comprimidos lanza varios en secuencia: extraer, volver a empaquetar y comprimir. Es decir, una petición puede tardar legítimamente más de sesenta segundos sin que nada esté fallando, y lo que se detiene a los sesenta es un paso concreto que se ha atascado.

Hay además un tope de expansión declarada de 2 GiB, que existe para el caso de un archivo que dice contener mucho más de lo que pesa. Y el cupo gratuito son cien conversiones de servidor por visitante y día, contadas por día UTC —se reinicia a medianoche en tiempo universal, no a la tuya—, más cinco peticiones por minuto como máximo. Las conversiones que ocurren en el navegador no cuentan para nada de eso.

Los tres no están ordenados de peor a mejor: están en puntos distintos de la misma curva. Gzip es el más rápido comprimiendo y descomprimiendo y el que menos ahorra. XZ ahorra mucho más sobre texto, a costa de bastante tiempo y de bastante memoria al desempaquetar. BZ2 queda en medio en proporción, es lento al descomprimir y el registro de este sitio lo marca como heredado.

Decide por lo que va a pasarle después al archivo. Algo que se va a descargar y desempaquetar muchas veces, en máquinas que no controlas, posiblemente en tubería: gzip. Algo que va a dormir años en almacenamiento frío y se va a leer casi nunca: XZ. Algo que tiene que coincidir con un nombre de artefacto que un sistema de compilación ya espera: el que diga ese nombre, sin más razonamiento. Convertir un tarball es barato, así que probar dos y comparar los tamaños es una forma perfectamente legítima de decidir.

La descarga termina en .gz y su contenido es un TAR, que es exactamente lo que significa la doble extensión habitual; renombrarlo para que acabe así lo describe mejor y permite desempaquetar las dos capas de una vez en lugar de dejar a alguien con un .tar suelto encima de la mesa.

Antes de que el original desaparezca, compara los listados: el del resultado contra el del archivo de partida, mismo número de entradas y mismas rutas. Lo que hay que mirar es el nivel superior, porque un archivo empaquetado desde dentro de un directorio y otro empaquetado desde su padre se diferencian en una carpeta al principio de cada entrada, y un script que esperaba uno y recibe el otro falla meses después por motivos que ya no recuerda nadie. Cuando los dos listados coinciden, el TAR sin comprimir ya no tiene ningún trabajo pendiente.