Tecnología · GUÍA PRÁCTICA
¿Gzip dice «unexpected end of file»? Demuestre los bytes antes de extraer otra vez
Un EOF puede indicar una descarga truncada, un flujo interrumpido o solo un fragmento de un archivo dividido. Conserve el artefacto, pruébelo y repare la ruta que falló.
«gzip: unexpected end of file» describe que el descompresor encontró un final prematuro, no la causa. Cambiar opciones de tar no recupera datos que nunca llegaron, y extraer algunos archivos no convierte un archivo parcial en fiable.
Creamos un miembro gzip determinista a partir de una carga de 151.552 bytes. El miembro completo de 514 bytes se descomprimió; al quitar su tráiler de ocho bytes apareció EOFError. La primera parte de 257 bytes también produjo EOFError, mientras que la segunda parte sola no tenía cabecera gzip. Al concatenar ambas en orden se recrearon exactamente el SHA-256 de 514 bytes y el hash de la carga original.
Esta prueba controlada respalda un orden de diagnóstico, no garantiza recuperación. Un archivo desconocido también puede estar dañado en medio, venir de una URL cambiante, quedar incompleto al generarse, concatenar varios miembros válidos o estar envuelto en otro formato. Conserve los bytes fallidos y obtenga el checksum o tamaño del productor cuando sea posible.
Congele el artefacto fallido antes de reintentar
Copie el archivo a una ruta de evidencia y registre bytes, SHA-256, URL o clave de objeto, cabeceras, hora y nombres de partes. No lo sobrescriba con otra descarga: podría borrar la diferencia que revela una transferencia inestable.
Ejecute gzip -t sobre la copia y conserve código de salida y stderr. La prueba lee todo el flujo y no confunde archivos extraídos parcialmente con éxito. Para entradas no fiables, use un directorio aislado y evite la extracción automática.
Separe descarga, flujo, partes y salida del productor
En una descarga, compare tamaño y hash con metadatos firmados o autenticados del editor. Compruebe si un proxy devolvió HTML, un rango terminó pronto o una reanudación añadió bytes incompatibles. Descargue con otro nombre y compare hashes antes de reemplazar.
En un flujo, capture tanto la finalización del transporte como el error. El caso de Node.js fallaba en puntos distintos al leer un objeto S3: eso exige revisar cierre, reintentos e identidad del objeto, no demuestra que un gzip grande sea inválido.
Reúna fragmentos solo con un manifiesto verificado
Si el productor usó split, inventaríe cada parte, tamaño o hash esperado y regla de orden. El caso de Unix & Linux muestra por qué part.000 termina antes que gzip: las partes pertenecen a un archivo y deben concatenarse en orden.
Escriba el resultado en un archivo nuevo. Compare el checksum fiable, ejecute gzip -t sobre ese archivo y después el consumidor real. Aprobar gzip demuestra integridad gzip, no la presencia de todos los registros de aplicación o miembros tar esperados.
Deténgase si no existen bytes de origen fiables
No acepte porque aparecieron algunos archivos, no corte bytes hasta que una prueba pase ni silencie el error. Así una falla visible se vuelve una omisión silenciosa. Solicite al editor o proceso anterior un objeto inmutable nuevo y su checksum.
Tras reparar, registre hashes anterior y nuevo, cambio de transferencia o unión, prueba gzip completa y verificación posterior. Mantenga las dudas explícitas; sin un artefacto autorizado describa el resultado como parcial, no completo.
