bzip2recover - récupère les données des fichiers bzip2 endommagés
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
un compresseur de fichiers de tri par blocs
décompresse les fichiers en stdout
récupère les données des fichiers bzip2 endommagés
bzip2 compresse les fichiers à l'aide de l'algorithme de compression de texte par tri de blocs Burrows-Wheeler et du codage Huffman. La compression est généralement considérablement meilleure que celle obtenue par des compresseurs basés sur LZ77/LZ78 plus conventionnels et se rapproche des performances de la famille PPM de compresseurs statistiques.
Les options de ligne de commande sont délibérément très similaires à celles de GNU gzip, mais elles ne sont pas identiques.
bzip2 s'attend à ce qu'une liste de noms de fichiers accompagne les drapeaux de la ligne de commande. Chaque fichier est remplacé par une version compressée de lui-même, avec le nom "original_name.bz2". Chaque fichier compressé a la même date de modification, les mêmes autorisations et, si possible, la même propriété que l'original correspondant, afin que ces propriétés puissent être correctement restaurées au moment de la décompression. La gestion des noms de fichiers est naïve en ce sens qu'il n'existe aucun mécanisme pour préserver les noms de fichiers originaux, les autorisations, les propriétaires ou les dates dans les systèmes de fichiers qui manquent de ces concepts ou qui ont de sérieuses restrictions de longueur de nom de fichier, comme MS-DOS.
bzip2 et bunzip2 n'écraseront pas par défaut les fichiers existants. Si vous voulez que cela se produise, spécifiez l'indicateur -f.
Si aucun nom de fichier n'est spécifié, bzip2 compresse de l'entrée standard à la sortie standard. Dans ce cas, bzip2 refusera d'écrire une sortie compressée sur un terminal, car cela serait totalement incompréhensible et donc inutile.
bunzip2 (ou bzip2 -d) décompresse tous les fichiers spécifiés. Les fichiers qui n'ont pas été créés par bzip2 seront détectés et ignorés, et un avertissement sera émis. bzip2 tente de deviner le nom du fichier décompressé à partir de celui du fichier compressé comme suit :
filename.bz2 becomes filename
filename.bz becomes filename
filename.tbz2 becomes filename.tar
filename.tbz becomes filename.tar
anyothername becomes anyothername.outSi le fichier ne se termine pas par l'une des terminaisons reconnues, .bz2, .bz, .tbz2 ou .tbz, bzip2 se plaint de ne pas pouvoir deviner le nom du fichier d'origine et utilise le nom d'origine avec .out ajouté.
Comme pour la compression, ne fournir aucun nom de fichier entraîne la décompression de l'entrée standard vers la sortie standard.
bunzip2 décompressera correctement un fichier qui est la concaténation de deux ou plusieurs fichiers compressés. Le résultat est la concaténation des fichiers non compressés correspondants. Le test d'intégrité (-t) des fichiers compressés concaténés est également pris en charge.
Vous pouvez également compresser ou décompresser des fichiers vers la sortie standard en donnant l'indicateur -c. Plusieurs fichiers peuvent être compressés et décompressés comme ceci. Les sorties résultantes sont envoyées séquentiellement à stdout. La compression de plusieurs fichiers de cette manière génère un flux contenant plusieurs représentations de fichiers compressés. Un tel flux ne peut être décompressé correctement que par bzip2 version 0.9.0 ou ultérieure. Les versions antérieures de bzip2 s'arrêteront après la décompression du premier fichier du flux.
bzcat (ou bzip2 -dc) décompresse tous les fichiers spécifiés vers la sortie standard.
bzip2 lira les arguments des variables d'environnement BZIP2 et BZIP, dans cet ordre, et les traitera avant tout argument lu depuis la ligne de commande. Cela donne un moyen pratique de fournir des arguments par défaut.
La compression est toujours effectuée, même si le fichier compressé est légèrement plus volumineux que l'original. Les fichiers de moins d'une centaine d'octets ont tendance à grossir, car le mécanisme de compression a une surcharge constante de l'ordre de 50 octets. Les données aléatoires (y compris la sortie de la plupart des compresseurs de fichiers) sont codées à environ 8,05 bits par octet, ce qui donne une expansion d'environ 0,5 %.
En guise d'auto-vérification pour votre protection, bzip2 utilise des CRC 32 bits pour s'assurer que la version décompressée d'un fichier est identique à l'original. Cela protège contre la corruption des données compressées et contre les bogues non détectés dans bzip2 (espérons-le très peu probable). Les chances que la corruption des données ne soit pas détectée sont microscopiques, environ une chance sur quatre milliards pour chaque fichier traité. Sachez cependant que la vérification se produit lors de la décompression, elle ne peut donc que vous dire que quelque chose ne va pas. Il ne peut pas vous aider à récupérer les données originales non compressées. Vous pouvez utiliser bzip2recover pour essayer de récupérer les données des fichiers endommagés.
Valeurs de retour : 0 pour une sortie normale, 1 pour des problèmes d'environnement (fichier introuvable, drapeaux invalides, erreurs d'E/S, etc.), 2 pour indiquer un fichier compressé corrompu, 3 pour une erreur de cohérence interne (par exemple, un bogue) qui a causé bzip2 pour paniquer.
Compresser ou décompresser en sortie standard.
Forcer la décompression. bzip2, bunzip2 et bzcat sont vraiment le même programme, et la décision sur les actions à entreprendre est prise sur la base du nom utilisé . Ce drapeau remplace ce mécanisme et force bzip2 à se décompresser.
Le complément à -d: force la compression, quel que soit le nom d'invocation.
Vérifiez l'intégrité du ou des fichiers spécifiés, mais ne les décompressez pas. Cela effectue vraiment une décompression d'essai et jette le résultat.
Forcer l'écrasement des fichiers de sortie. Normalement, bzip2 n'écrasera pas les fichiers de sortie existants. Force également bzip2 à rompre les liens physiques vers les fichiers, ce qu'il ne ferait pas autrement.
bzip2 refuse normalement de décompresser les fichiers qui n'ont pas les octets d'en-tête magiques corrects. S'il est forcé (-f), cependant, il transmettra ces fichiers sans modification. C'est ainsi que GNU gzip se comporte.
Conservez (ne supprimez pas) les fichiers d'entrée pendant la compression ou la décompression.
Réduisez l'utilisation de la mémoire, pour la compression, la décompression et les tests. Les fichiers sont décompressés et testés à l'aide d'un algorithme modifié qui ne nécessite que 2,5 octets par octet de bloc. Cela signifie que n'importe quel fichier peut être décompressé dans 2300 Ko de mémoire, mais à environ la moitié de la vitesse normale.
Pendant la compression, -s sélectionne une taille de bloc de 200 Ko, ce qui limite l'utilisation de la mémoire à peu près au même chiffre, au détriment de votre taux de compression. En bref, si votre machine manque de mémoire (8 mégaoctets ou moins), utilisez -s pour tout. Voir GESTION DE LA MÉMOIRE ci-dessous.
Supprimer les messages d'avertissement non essentiels. Les messages relatifs aux erreurs d'E/S et autres événements critiques ne seront pas supprimés.
Mode détaillé -- affiche le taux de compression pour chaque fichier traité. De plus, les -v augmentent le niveau de verbosité, crachant beaucoup d'informations qui sont principalement intéressantes à des fins de diagnostic.
Affichez la version du logiciel, les termes et conditions de la licence.
Réglez la taille du bloc sur 100 k, 200 k .. 900 k lors de la compression. N'a aucun effet lors de la décompression. Voir GESTION DE LA MÉMOIRE ci-dessous. Les alias --fast et --best sont principalement destinés à la compatibilité GNU gzip. En particulier, --fast ne rend pas les choses beaucoup plus rapides. Et --best sélectionne simplement le comportement par défaut.
Traite tous les arguments suivants comme des noms de fichiers, même s'ils commencent par un tiret. Cela vous permet de gérer les fichiers dont le nom commence par un tiret, par exemple : bzip2 -- -myfilename.
Ces drapeaux sont redondants dans les versions 0.9.5 et supérieures. Ils ont fourni un contrôle grossier sur le comportement de l'algorithme de tri dans les versions antérieures, ce qui était parfois utile. 0.9.5 et supérieur ont un algorithme amélioré qui rend ces drapeaux non pertinents.
bzip2 compresse les fichiers volumineux en blocs. La taille de bloc affecte à la fois le taux de compression atteint et la quantité de mémoire nécessaire pour la compression et la décompression. Les drapeaux -1 à -9 spécifient la taille de bloc de 100 000 octets à 900 000 octets (la valeur par défaut) respectivement. Au moment de la décompression, la taille de bloc utilisée pour la compression est lue à partir de l'en-tête du fichier compressé, et bunzip2 s'alloue alors juste assez de mémoire pour décompresser le fichier. Étant donné que les tailles de bloc sont stockées dans des fichiers compressés, il s'ensuit que les drapeaux -1 à -9 ne sont pas pertinents et sont donc ignorés lors de la décompression.
Les exigences de compression et de décompression, en octets, peuvent être estimées comme suit :
Compression:
400k + ( 8 x block size )
Décompression:
100k + ( 4 x block size ), or 100k + ( 2.5 x block size )
Des tailles de bloc plus grandes donnent des rendements marginaux qui diminuent rapidement. La majeure partie de la compression provient des deux ou trois cents premiers k de taille de bloc, un fait qu'il convient de garder à l'esprit lors de l'utilisation de bzip2 sur de petites machines. Il est également important de comprendre que l'exigence de mémoire de décompression est définie au moment de la compression par le choix de la taille de bloc.
Pour les fichiers compressés avec la taille de bloc par défaut de 900 ko, bunzip2 nécessitera environ 3 700 ko pour être décompressés. Pour prendre en charge la décompression de n'importe quel fichier sur une machine de 4 Mo, bunzip2 a une option pour décompresser en utilisant approximativement la moitié de cette quantité de mémoire, environ 2300 Ko. La vitesse de décompression est également réduite de moitié, vous ne devez donc utiliser cette option que lorsque cela est nécessaire. L'indicateur pertinent est -s.
En général, essayez d'utiliser la plus grande taille de bloc autorisée par les contraintes de mémoire, car cela maximise la compression obtenue. La vitesse de compression et de décompression n'est pratiquement pas affectée par la taille des blocs.
Un autre point important s'applique aux fichiers qui tiennent dans un seul bloc - cela signifie que la plupart des fichiers que vous rencontrerez utilisent une grande taille de bloc. La quantité de mémoire réelle touchée est proportionnelle à la taille du fichier, puisque le fichier est plus petit qu'un bloc. Par exemple, compresser un fichier de 20 000 octets avec l'indicateur -9 obligera le compresseur à allouer environ 7 600 ko de mémoire, mais n'en touchera que 400 ko + 20 000 * 8=560 ko. De même, le décompresseur allouera 3700k mais ne touchera que 100k + 20000 * 4=180 ko.
Voici un tableau qui résume l'utilisation maximale de la mémoire pour différentes tailles de bloc. La taille totale compressée de 14 fichiers du Calgary Text Compression Corpus totalisant 3 141 622 octets est également enregistrée. Cette colonne donne une idée de la façon dont la compression varie avec la taille du bloc. Ces chiffres ont tendance à sous-estimer l'avantage des tailles de bloc plus grandes pour les fichiers plus volumineux, puisque le Corpus est dominé par des fichiers plus petits.
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 compresse les fichiers en blocs, généralement de 900 Ko de long. Chaque bloc est géré indépendamment. Si une erreur de support ou de transmission endommage un fichier .bz2 multibloc, il peut être possible de récupérer les données des blocs non endommagés dans le fichier.
La représentation compressée de chaque bloc est délimitée par un motif de 48 bits, ce qui permet de trouver les limites de bloc avec une certitude raisonnable. Chaque bloc porte également son propre CRC 32 bits, de sorte que les blocs endommagés peuvent être distingués des blocs non endommagés.
bzip2recover est un programme simple dont le but est de rechercher des blocs dans les fichiers .bz2 et d'écrire chaque bloc dans son propre fichier .bz2. Vous pouvez ensuite utiliser bzip2 -t pour tester l'intégrité des fichiers résultants et décompresser ceux qui ne sont pas endommagés.
bzip2recover prend un seul argument, le nom du fichier endommagé, et écrit un certain nombre de fichiers "rec00001file.bz2", "rec00002file.bz2", etc, contenant les blocs extraits. Les noms de fichiers de sortie sont conçus de sorte que l'utilisation de caractères génériques dans le traitement ultérieur -- par exemple, "bzip2 -dc rec*file.bz2 > recovery_data" -- traite les fichiers dans le bon ordre.
bzip2recover devrait être le plus utile pour traiter les gros fichiers .bz2, car ceux-ci contiendront de nombreux blocs. Il est clairement inutile de l'utiliser sur des fichiers monobloc endommagés, car un bloc endommagé ne peut pas être récupéré. Si vous souhaitez minimiser toute perte de données potentielle due à des erreurs de support ou de transmission, vous pouvez envisager de compresser avec une taille de bloc plus petite.
La phase de tri de la compression rassemble les chaînes similaires dans le fichier. Pour cette raison, les fichiers contenant de très longues séries de symboles répétés, comme "aabaabaabaab ..." (répété plusieurs centaines de fois) peuvent se compresser plus lentement que la normale. Les versions 0.9.5 et supérieures s'en sortent bien mieux que les versions précédentes à cet égard. Le rapport entre le pire cas et le temps de compression moyen est de l'ordre de 10:1. Pour les versions précédentes, ce chiffre était plutôt de 100:1. Vous pouvez utiliser l'option -vvvv pour surveiller la progression en détail, si vous le souhaitez.
La vitesse de décompression n'est pas affectée par ces phénomènes.
bzip2 alloue généralement plusieurs mégaoctets de mémoire pour fonctionner, puis charge tout de manière assez aléatoire. Cela signifie que les performances, à la fois pour la compression et la décompression, sont largement déterminées par la vitesse à laquelle votre machine peut réparer les échecs de cache. Pour cette raison, de petites modifications du code visant à réduire le taux d'échec ont été observées pour apporter des améliorations de performances disproportionnées. J'imagine que bzip2 fonctionnera mieux sur des machines avec de très grands caches.
Les messages d'erreur d'E/S ne sont pas aussi utiles qu'ils pourraient l'être. bzip2 s'efforce de détecter les erreurs d'E/S et de quitter proprement, mais les détails du problème semblent parfois plutôt trompeurs.
Cette page de manuel concerne la version 1.0.8 de bzip2. Les données compressées créées par cette version sont entièrement compatibles en amont et en aval avec les versions publiques précédentes, versions 0.1pl2, 0.9.0, 0.9.5, 1.0 .0, 1.0.1, 1.0.2 et supérieur, mais avec l'exception suivante : 0.9.0 et supérieur peuvent décompresser correctement plusieurs fichiers compressés concaténés. 0.1pl2 ne peut pas faire cela ; il s'arrêtera après avoir décompressé uniquement le premier fichier du flux.
Les versions de bzip2recover antérieures à la 1.0.2 utilisaient des entiers 32 bits pour représenter les positions des bits dans les fichiers compressés, de sorte qu'elles ne pouvaient pas gérer les fichiers compressés de plus de 512 mégaoctets de long. Les versions 1.0.2 et supérieures utilisent des entiers 64 bits sur certaines plates-formes qui les prennent en charge (cibles prises en charge par GNU et Windows). Pour établir si oui ou non bzip2recover a été construit avec une telle limitation, exécutez-le sans arguments. Dans tous les cas, vous pouvez créer vous-même une version illimitée si vous pouvez la recompiler avec MaybeUInt64 défini comme un entier 64 bits non signé.
Julian Seward, jseward@acm.org.
https://sourceware.org/bzip2/
Les idées incarnées dans bzip2 sont dues (au moins) aux personnes suivantes : Michael Burrows et David Wheeler (pour la transformation de tri par blocs), David Wheeler (encore une fois, pour le codeur Huffman), Peter Fenwick ( pour le modèle de codage structuré dans le bzip d'origine, et de nombreux raffinements), et Alistair Moffat, Radford Neal et Ian Witten (pour le codeur arithmétique dans le bzip d'origine). I Je leur suis très reconnaissant pour leur aide, leur soutien et leurs conseils. Voir le manuel dans la distribution des sources pour des pointeurs vers les sources de documentation. Christian von Roques m'a encouragé à rechercher des algorithmes de tri plus rapides, afin d'accélérer la compression. Bela Lubkin m'a encouragé à améliorer les performances de compression dans le pire des cas. Donna Robinson a XMLisé la documentation. Les scripts bz* sont dérivés de ceux de GNU gzip. De nombreuses personnes ont envoyé des correctifs, ont aidé à résoudre des problèmes de portabilité, ont prêté des machines, ont donné des conseils et ont généralement été utiles.