bzip2recover - recupera datos de archivos bzip2 dañados
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
un compresor de archivos de clasificación de bloques
descomprime archivos a stdout
recupera datos de archivos bzip2 dañados
bzip2 comprime archivos utilizando el algoritmo de compresión de texto de clasificación de bloques de Burrows-Wheeler y la codificación Huffman. En general, la compresión es considerablemente mejor que la lograda por los compresores basados en LZ77/LZ78 más convencionales y se acerca al rendimiento de la familia de compresores estadísticos PPM.
Las opciones de la línea de comandos son deliberadamente muy similares a las de GNU gzip, pero no son idénticas.
bzip2 espera que una lista de nombres de archivos acompañe a las banderas de la línea de comandos. Cada archivo se reemplaza por una versión comprimida de sí mismo, con el nombre "original_name.bz2". Cada archivo comprimido tiene la misma fecha de modificación, permisos y, en lo posible, propiedad que el original correspondiente, de modo que estas propiedades puedan restaurarse correctamente en el momento de la descompresión. El manejo de nombres de archivo es ingenuo en el sentido de que no existe un mecanismo para preservar los nombres de archivo originales, los permisos, las propiedades o las fechas en los sistemas de archivos que carecen de estos conceptos o que tienen serias restricciones de longitud de nombre de archivo, como MS-DOS.
bzip2 y bunzip2 por defecto no sobrescribirán los archivos existentes. Si desea que esto suceda, especifique el indicador -f.
Si no se especifica ningún nombre de archivo, bzip2 comprime desde la entrada estándar a la salida estándar. En este caso, bzip2 se negará a escribir la salida comprimida en una terminal, ya que esto sería completamente incomprensible y, por lo tanto, sin sentido.
bunzip2 (o bzip2 -d) descomprime todos los archivos especificados. Los archivos que no fueron creados por bzip2 serán detectados e ignorados, y se emitirá una advertencia. bzip2 intenta adivinar el nombre del archivo descomprimido a partir del archivo comprimido de la siguiente manera:
filename.bz2 becomes filename
filename.bz becomes filename
filename.tbz2 becomes filename.tar
filename.tbz becomes filename.tar
anyothername becomes anyothername.outSi el archivo no termina en una de las terminaciones reconocidas, .bz2, .bz, .tbz2 o .tbz, bzip2 se queja de que no puede adivinar el nombre del archivo original y usa el nombre original con .out adjunto.
Al igual que con la compresión, no proporcionar nombres de archivo provoca la descompresión de la entrada estándar a la salida estándar.
bunzip2 descomprimirá correctamente un archivo que es la concatenación de dos o más archivos comprimidos. El resultado es la concatenación de los correspondientes archivos sin comprimir. También se admiten pruebas de integridad (-t) de archivos comprimidos concatenados.
También puede comprimir o descomprimir archivos a la salida estándar dando el indicador -c. Se pueden comprimir y descomprimir varios archivos de esta manera. Las salidas resultantes se alimentan secuencialmente a stdout. La compresión de múltiples archivos de esta manera genera un flujo que contiene múltiples representaciones de archivos comprimidos. Este flujo solo se puede descomprimir correctamente con bzip2 versión 0.9.0 o posterior. Las versiones anteriores de bzip2 se detendrán después de descomprimir el primer archivo de la transmisión.
bzcat (o bzip2 -dc) descomprime todos los archivos especificados a la salida estándar.
bzip2 leerá los argumentos de las variables de entorno BZIP2 y BZIP, en ese orden, y los procesará antes de leer los argumentos de la línea de comandos. Esto brinda una forma conveniente de proporcionar argumentos predeterminados.
La compresión siempre se realiza, incluso si el archivo comprimido es un poco más grande que el original. Los archivos de menos de cien bytes tienden a aumentar de tamaño, ya que el mecanismo de compresión tiene una sobrecarga constante en la región de 50 bytes. Los datos aleatorios (incluida la salida de la mayoría de los compresores de archivos) se codifican a unos 8,05 bits por byte, lo que da una expansión de alrededor del 0,5 %.
Como autocomprobación para su protección, bzip2 utiliza CRC de 32 bits para asegurarse de que la versión descomprimida de un archivo sea idéntica a la original. Esto protege contra la corrupción de los datos comprimidos y contra errores no detectados en bzip2 (con suerte, muy poco probable). Las posibilidades de que la corrupción de datos pase desapercibida son microscópicas, aproximadamente una posibilidad entre cuatro mil millones por cada archivo procesado. Tenga en cuenta, sin embargo, que la comprobación se produce durante la descompresión, por lo que solo puede indicarle que algo anda mal. No puede ayudarlo a recuperar los datos originales sin comprimir. Puede usar bzip2recover para intentar recuperar datos de archivos dañados.
Valores devueltos: 0 para una salida normal, 1 para problemas ambientales (archivo no encontrado, indicadores no válidos, errores de E/S, etc.), 2 para indicar un archivo comprimido corrupto, 3 para un error de coherencia interna (por ejemplo, error) que causó bzip2 para entrar en pánico.
Comprimir o descomprimir a la salida estándar.
Forzar la descompresión. bzip2, bunzip2 y bzcat son realmente el mismo programa, y la decisión sobre qué acciones tomar se toma en base al nombre que se usa . Esta bandera anula ese mecanismo y obliga a bzip2 a descomprimirse.
El complemento de -d: fuerza la compresión, independientemente del nombre de la invocación.
Verifique la integridad de los archivos especificados, pero no los descomprima. Esto realmente realiza una descompresión de prueba y descarta el resultado.
Forzar la sobrescritura de los archivos de salida. Normalmente, bzip2 no sobrescribirá los archivos de salida existentes. También obliga a bzip2 a romper enlaces duros a archivos, lo que de otro modo no haría.
bzip2 normalmente se niega a descomprimir archivos que no tienen los bytes de encabezado mágico correctos. Sin embargo, si se fuerza (-f), pasará dichos archivos sin modificar. Así es como se comporta GNU gzip.
Mantenga (no elimine) los archivos de entrada durante la compresión o descompresión.
Reduzca el uso de memoria, para compresión, descompresión y pruebas. Los archivos se descomprimen y prueban mediante un algoritmo modificado que solo requiere 2,5 bytes por byte de bloque. Esto significa que cualquier archivo se puede descomprimir en 2300k de memoria, aunque a la mitad de la velocidad normal.
Durante la compresión, -s selecciona un tamaño de bloque de 200k, lo que limita el uso de la memoria a aproximadamente la misma cifra, a expensas de la relación de compresión. En resumen, si su máquina tiene poca memoria (8 megabytes o menos), use -s para todo. Consulte ADMINISTRACIÓN DE LA MEMORIA a continuación.
Suprime los mensajes de advertencia no esenciales. Los mensajes relacionados con errores de E/S y otros eventos críticos no se suprimirán.
Modo detallado: muestra la relación de compresión para cada archivo procesado. Además, los -v aumentan el nivel de verbosidad, arrojando mucha información que es principalmente de interés para fines de diagnóstico.
Muestra la versión del software, los términos y condiciones de la licencia.
Establezca el tamaño del bloque en 100 k, 200 k .. 900 k al comprimir. No tiene efecto al descomprimir. Consulte ADMINISTRACIÓN DE LA MEMORIA a continuación. Los alias --fast y --best son principalmente para la compatibilidad con GNU gzip. En particular, --fast no hace que las cosas sean significativamente más rápidas. Y --best simplemente selecciona el comportamiento predeterminado.
Trata todos los argumentos posteriores como nombres de archivo, incluso si comienzan con un guión. Esto es para que pueda manejar archivos con nombres que comiencen con un guión, por ejemplo: bzip2 -- -myfilename.
Estos indicadores son redundantes en las versiones 0.9.5 y superiores. Proporcionaron un control aproximado sobre el comportamiento del algoritmo de clasificación en versiones anteriores, lo que a veces resultó útil. 0.9.5 y superior tienen un algoritmo mejorado que hace que estas banderas sean irrelevantes.
bzip2 comprime archivos grandes en bloques. El tamaño del bloque afecta tanto la relación de compresión lograda como la cantidad de memoria necesaria para la compresión y descompresión. Los indicadores -1 a -9 especifican que el tamaño del bloque sea de 100 000 bytes a 900 000 bytes (el valor predeterminado) respectivamente. En el momento de la descompresión, el tamaño del bloque utilizado para la compresión se lee del encabezado del archivo comprimido y bunzip2 se asigna la memoria suficiente para descomprimir el archivo. Dado que los tamaños de bloque se almacenan en archivos comprimidos, se deduce que los indicadores -1 a -9 son irrelevantes y, por lo tanto, se ignoran durante la descompresión.
Los requisitos de compresión y descompresión, en bytes, se pueden estimar como:
Compresión:
400k + ( 8 x block size )
Descompresión:
100k + ( 4 x block size ), or 100k + ( 2.5 x block size )
Los tamaños de bloque más grandes dan rendimientos marginales rápidamente decrecientes. La mayor parte de la compresión proviene de los primeros doscientos o trescientos k de tamaño de bloque, un hecho que vale la pena tener en cuenta al usar bzip2 en máquinas pequeñas. También es importante apreciar que el requisito de memoria de descompresión se establece en el momento de la compresión mediante la elección del tamaño del bloque.
Para archivos comprimidos con el tamaño de bloque predeterminado de 900k, bunzip2 requerirá alrededor de 3700 kbytes para descomprimirse. Para admitir la descompresión de cualquier archivo en una máquina de 4 megabytes, bunzip2 tiene una opción para descomprimir utilizando aproximadamente la mitad de esta cantidad de memoria, aproximadamente 2300 kbytes. La velocidad de descompresión también se reduce a la mitad, por lo que debe usar esta opción solo cuando sea necesario. La bandera relevante es -s.
En general, intente usar el tamaño de bloque más grande que permitan las restricciones de memoria, ya que eso maximiza la compresión lograda. La velocidad de compresión y descompresión prácticamente no se ve afectada por el tamaño del bloque.
Otro punto importante se aplica a los archivos que caben en un solo bloque, lo que significa que la mayoría de los archivos que encontraría usarían un tamaño de bloque grande. La cantidad de memoria real tocada es proporcional al tamaño del archivo, ya que el archivo es más pequeño que un bloque. Por ejemplo, comprimir un archivo de 20 000 bytes de largo con el indicador -9 hará que el compresor asigne alrededor de 7600 k de memoria, pero solo tocará 400 k + 20 000 * 8=560 kbytes. De manera similar, el descompresor asignará 3700k pero solo tocará 100k + 20000 * 4=180 kbytes.
Aquí hay una tabla que resume el uso máximo de memoria para diferentes tamaños de bloque. También se registra el tamaño comprimido total de 14 archivos del Corpus de compresión de texto de Calgary con un total de 3.141.622 bytes. Esta columna da una idea de cómo varía la compresión con el tamaño del bloque. Estas cifras tienden a subestimar la ventaja de tamaños de bloque más grandes para archivos más grandes, ya que el Corpus está dominado por archivos más pequeños.
Compress Decompress Decompress Corpus
Flag usage usage -s usage Size
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642bzip2 comprime archivos en bloques, normalmente de 900 kbytes de longitud. Cada bloque se maneja de forma independiente. Si un error de medios o de transmisión hace que un archivo .bz2 de varios bloques se dañe, es posible recuperar los datos de los bloques no dañados del archivo.
La representación comprimida de cada bloque está delimitada por un patrón de 48 bits, lo que permite encontrar los límites de los bloques con una certeza razonable. Cada bloque también lleva su propio CRC de 32 bits, por lo que los bloques dañados se pueden distinguir de los que no están dañados.
bzip2recover es un programa simple cuyo propósito es buscar bloques en archivos .bz2 y escribir cada bloque en su propio archivo .bz2. Luego puede usar bzip2 -t para probar la integridad de los archivos resultantes y descomprimir aquellos que no están dañados.
bzip2recover toma un único argumento, el nombre del archivo dañado, y escribe una serie de archivos "rec00001file.bz2", "rec00002file.bz2", etc., que contienen los bloques extraídos. Los nombres de archivo de salida están diseñados para que el uso de comodines en el procesamiento posterior, por ejemplo, "bzip2 -dc rec*file.bz2 > datos_recuperados", procese los archivos en el orden correcto.
bzip2recover debería ser de gran utilidad al tratar con archivos grandes .bz2, ya que estos contendrán muchos bloques. Evidentemente, es inútil usarlo en archivos de un solo bloque dañados, ya que un bloque dañado no se puede recuperar. Si desea minimizar cualquier posible pérdida de datos a través de errores de medios o transmisión, puede considerar comprimir con un tamaño de bloque más pequeño.
La fase de clasificación de la compresión reúne cadenas similares en el archivo. Debido a esto, los archivos que contienen series muy largas de símbolos repetidos, como "aabaabaabaab ..." (repetidos varios cientos de veces) pueden comprimirse más lentamente de lo normal. A las versiones 0.9.5 y superiores les va mucho mejor que a las versiones anteriores en este sentido. La relación entre el tiempo de compresión en el peor de los casos y en el caso promedio está en la región de 10:1. Para versiones anteriores, esta cifra era más como 100:1. Puede usar la opción -vvvv para monitorear el progreso con gran detalle, si lo desea.
La velocidad de descompresión no se ve afectada por estos fenómenos.
bzip2 por lo general asigna varios megabytes de memoria para operar y luego los carga de forma bastante aleatoria. Esto significa que el rendimiento, tanto para comprimir como para descomprimir, está determinado en gran medida por la velocidad a la que su máquina puede atender errores de caché. Debido a esto, se ha observado que pequeños cambios en el código para reducir la tasa de fallas brindan mejoras de rendimiento desproporcionadamente grandes. Me imagino que bzip2 funcionará mejor en máquinas con cachés muy grandes.
Los mensajes de error de E/S no son tan útiles como podrían ser. bzip2 se esfuerza por detectar errores de E/S y salir limpiamente, pero los detalles del problema a veces parecen bastante engañosos.
Esta página del manual pertenece a la versión 1.0.8 de bzip2. Los datos comprimidos creados por esta versión son completamente compatibles hacia adelante y hacia atrás con las versiones públicas anteriores, versiones 0.1pl2, 0.9.0, 0.9.5, 1.0 .0, 1.0.1, 1.0.2 y posteriores, pero con la siguiente excepción: 0.9.0 y posteriores pueden descomprimir correctamente varios archivos comprimidos concatenados. 0.1pl2 no puede hacer esto; se detendrá después de descomprimir solo el primer archivo de la transmisión.
Las versiones de bzip2recover anteriores a la 1.0.2 usaban números enteros de 32 bits para representar posiciones de bits en archivos comprimidos, por lo que no podían manejar archivos comprimidos de más de 512 megabytes de longitud. Las versiones 1.0.2 y superiores usan entradas de 64 bits en algunas plataformas que las admiten (destinos compatibles con GNU y Windows). Para establecer si bzip2recover se creó o no con tal limitación, ejecútelo sin argumentos. En cualquier caso, puede crear una versión ilimitada si puede volver a compilarla con MaybeUInt64 configurado para que sea un número entero de 64 bits sin signo.
Julián Seward, jseward@acm.org.
https://sourceware.org/bzip2/
Las ideas plasmadas en bzip2 se deben a (al menos) las siguientes personas: Michael Burrows y David Wheeler (para la transformación de clasificación de bloques), David Wheeler (nuevamente, para el codificador de Huffman), Peter Fenwick ( para el modelo de codificación estructurada en el bzip original, y muchas mejoras), y Alistair Moffat, Radford Neal e Ian Witten (para el codificador aritmético en el bzip original). I Estoy muy en deuda por su ayuda, apoyo y consejos. Consulte el manual en la distribución de origen para obtener indicaciones sobre las fuentes de documentación. Christian von Roques me animó a buscar algoritmos de clasificación más rápidos para acelerar la compresión. Bela Lubkin me animó a mejorar el rendimiento de compresión en el peor de los casos. Donna Robinson XMLizó la documentación. Los scripts bz* se derivan de los de GNU gzip. Muchas personas enviaron parches, ayudaron con problemas de portabilidad, prestaron máquinas, dieron consejos y en general fueron útiles.