# [tar/bzip2] Archive "corrompue" vs interface chaise-clavier

## yoyo

Bonjour/bonsoir à tous,

Depuis quelques temps déjà, je songeai à changer de fs (reiser4=>xfs pour les curieux) pour mon système GNU/Linux.

Suite à un problème de freeze et reboot au "magic sys keys" mon fs a eu besoin d'un fsck.

Je démarre donc sur un livecd et je lance le check. La réparation se passe sans problème et je me dis que tant que je suis là je vais migrer mon système à l'ancienne (sinon j'aurai utilisé la méthode du stage5 et ça m'aurait surement évité pas mal de problèmes).

Et me voila parti :

```

 tar cjpf

 mkfs.xfs

 tar xpjf ... BLAM !!

```

Oui, je n'ai pas vérifié mon archive avant le mkfs ! Oui je suis trop confiant dans mon système et mon matériel !   :Embarassed: 

Voila le type de message d'erreur que j'obtiens :

```

 tar xjf the_bad_bad_backup.tar.bz2

bzip2: Data integrity error when decompressing.

Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.

You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to *attempt* to recover

data from undamaged sections of corrupted files.

tar: 56 garbage bytes ignored at end of archive

tar: Unexpected EOF in archive

tar: Unexpected EOF in archive

tar: Error is not recoverable: exiting now

```

mis à part que la décompression démarre sans problème (je récupère mon "/etc" et une partie de mon "/home") et que c'est sur un fichier sans importance que le problème survient.

L'idée c'est donc de virer ce fichier de l'archive ou de "forcer" la restauration même si l'intégrité de l'archive n'est pas bonne sur ce fichier. Si vous connaissez une commande ou une option, je suis preneur !

Sinon, j'ai trouvé un tutoriel utilisant "bzip2recover" (oui, je lis les messages d'erreurs, pas comme certains   :Twisted Evil:   ) : howto repair corrupt tar archives mais il implique de bunziper toute l'archive et je ne dois pas avoir de partition suffisamment grande pour ça. Je pourrai éventuellement refaire mon plan de partitionnement, "réparer" l'archive en suivant le tutoriel, créer une nouvelle archive, la contrôler (je ne me ferai pas avoir deux fois !!), refaire mon plan de partitionnement et restaurer mon système.

Enfin c'est quand même très très lourd.   :Sad: 

Je compte donc sur vos compétences !   :Wink: 

Enjoy !

----------

## ghoti

 *yoyo wrote:*   

> L'idée c'est donc de virer ce fichier de l'archive ou de "forcer" la restauration même si l'intégrité de l'archive n'est pas bonne sur ce fichier. Si vous connaissez une commande ou une option, je suis preneur !

 

As-tu essayé l'option --exclude ?

----------

## widan

 *yoyo wrote:*   

> L'idée c'est donc de virer ce fichier de l'archive ou de "forcer" la restauration même si l'intégrité de l'archive n'est pas bonne sur ce fichier. Si vous connaissez une commande ou une option, je suis preneur !

 

J'ai peur que ça ne serve à rien, c'est corrompu au niveau de la compression bzip2 (c'est la décompression qui pose problème, le fait que tar bloque n'est que la conséquence du fait que bunzip2 a tronqué le fichier après l'erreur). Si c'était au niveau du tar ce serait bien plus simple. Tu peux vérifier que le problème est bien au niveau du wrapper bzip2 en faisant:

```
$ bunzip2 -t <ton_fichier_tbz2>
```

 *yoyo wrote:*   

> ... mais il implique de bunziper toute l'archive et je ne dois pas avoir de partition suffisamment grande pour ça ...

 

Il faudra bien... ce n'est pas possible de réparer un fichier compressé en place à ma connaissance.

----------

## Enlight

Bon je me suis un peu creusé le citron sur le sujêt, je pense qu'il y'aurait un moyen.

Le but serait d'extraire des bouts d'archive style dd if=corrompu.tbz bs=4096 count=4 skip=foo. bzip2recover n'ayant pas besoin de l'en-tête, il nous sort un rec comme il faut. Après y'aurait plus qu'appliquer la méthode du script perl (qui cherche un "magic" dans le rec, et au passage qui est codé avec les pieds) puis de passer celui-ci à tar.

Le plus gros problème ce serait les fichiers à cheval sur plusieurs de nos splits, il faudrait jouer la redondance en s'assurant que parmis les premiers fichiers du morceau d'archive corrompue, on a à chaque fois le dernier fichier de la partie précédente.

Faudrait aussi voir en amont si l'archive est corrompue en soi, où si elle est situées sur des secteurs de disque defectueux, ça peut se faire en extrayant 2 fois chaque morceaux de l'archive et en les comparants.

J'essayerai quelques trucs demain soir encore, mais là dodo.

----------

## ghoti

 *widan wrote:*   

>  *yoyo wrote:*   L'idée c'est donc de virer ce fichier de l'archive ou de "forcer" la restauration même si l'intégrité de l'archive n'est pas bonne sur ce fichier. Si vous connaissez une commande ou une option, je suis preneur ! 
> 
> J'ai peur que ça ne serve à rien, c'est corrompu au niveau de la compression bzip2.

 

D'où l'idée d'exclure le fichier qui pose problème : si l'erreur se situe au niveau de la reconnaissance du fichier par bzip, alors oui, on est mal bar. Mais si c'est simplement la moitié du quart d'un bit qui pose problème pour la décompression alors là les chances restent entières.

Je maintiens ma proposition en croisant les doigts ...  :Wink: 

@ Enlight : en effet, des splits, ça serait chouette mais combiner la gestion bzip et la gestion tar, ça ne me paraît pas évident du tout.

Mais on me dit souvent que je suis d'un naturel pessimiste ...

----------

## Enlight

Pffff il va me forcer à prendre les paris...

----------

## ghoti

Non non : j'espère au contraire qu'en dernier recours tu aies raison !  :Smile: 

Mais il faut tout de même reconnaître que découper un tar bzipé, c'est pas gagné d'avance !   :Confused: 

----------

## widan

 *Enlight wrote:*   

> Faudrait aussi voir en amont si l'archive est corrompue en soi, où si elle est situées sur des secteurs de disque defectueux, ça peut se faire en extrayant 2 fois chaque morceaux de l'archive et en les comparants.

 

Ca peut être le disque... Même si la plupart des erreurs ferait plutôt une erreur I/O, il peut se passer quelque chose comme ça: le secteur est écrit dans le cache du disque, qui indique que l'écriture est terminée, puis erreur lors de la vraie écriture sur le média - mais c'est trop tard pour le signaler à l'OS (puisque déjà indiqué comme OK) et ce secteur est perdu. Ca peut aussi être une barrette de RAM défectueuse. Mais de toute façon il vaudrait mieux savoir ce qui a causé la corruption pour éviter que ça cause d'autres dégâts (pendant la réparation de l'archive ou après).

 *ghoti wrote:*   

> D'où l'idée d'exclure le fichier qui pose problème : si l'erreur se situe au niveau de la reconnaissance du fichier par bzip, alors oui, on est mal barré.

 

L'erreur vient de bunzip2 initialement. En fait bzip2 inclut un checksum dans chaque bloc, et lors de la décompression il vérifie que les données décompressées correspondent au checksum. Si ça correspond pas on a l'erreur du départ ("Data integrity error ..."). Mais on peut toujours tenter...

 *ghoti wrote:*   

> Mais si c'est simplement la moitié du quart d'un bit qui pose problème pour la décompression alors là les chances restent entières.

 

Dans un fichier compressé un seul bit changé peut avoir beaucoup de conséquences. La compression bzip2 est faite par blocs. Normalement on peut récupérer tout les fichiers qui sont entièrement dans des blocs non concernés par l'erreur (en espérant que ça soit une erreur isolée et pas un disque plein de secteurs défectueux).

----------

## ghoti

 *widan wrote:*   

> Normalement on peut récupérer tout les fichiers qui sont entièrement dans des blocs non concernés par l'erreur (en espérant que ça soit une erreur isolée et pas un disque plein de secteurs défectueux).

 

Bon, alors, le problème se réduirait à exclure les blocs en question.

Malheureusement, je ne vois pas d'options en ce sens dans man bzip2 ?   :Confused: 

Il faudrait un truc capable de se resynchroniser mais j'avoue que je n'ai pas de réponse immédiate  :Sad: 

----------

## yoyo

Tout d'abord, merci à tous pour les différentes pistes proposés.   :Smile: 

 *Enlight wrote:*   

> Faudrait aussi voir en amont si l'archive est corrompue en soi, où si elle est situées sur des secteurs de disque defectueux, ça peut se faire en extrayant 2 fois chaque morceaux de l'archive et en les comparants.

 A priori ça n'est pas un problème hard car j'ai pu copier l'archive sur un autre disque sans aucun problème.

 *widan wrote:*   

> Mais de toute façon il vaudrait mieux savoir ce qui a causé la corruption pour éviter que ça cause d'autres dégâts (pendant la réparation de l'archive ou après).

 J'ai ma petite idée la dessus; en fait j'ai fait un "fsck.resier4 --fix" sur mes partitions mais je n'ai pas redémarré dessus pour les tester. Et je me demande si cela ne viendrait pas de là ... Enfin le fsck a fonctionné sans aucun avertissement donc a priori ça n'est pas ça; mais reiser4 recquiert peut-être une utilisation ultérieure pour remettre son journal dans l'ordre (théorie purement spéculative et sans aucun fondement technique ou scientifique).

 *widan wrote:*   

>  *ghoti wrote:*   D'où l'idée d'exclure le fichier qui pose problème : si l'erreur se situe au niveau de la reconnaissance du fichier par bzip, alors oui, on est mal barré. L'erreur vient de bunzip2 initialement. En fait bzip2 inclut un checksum dans chaque bloc, et lors de la décompression il vérifie que les données décompressées correspondent au checksum. Si ça correspond pas on a l'erreur du départ ("Data integrity error ..."). Mais on peut toujours tenter...

 C'est ce qu'il m'avait semblé (le checsum sur chaque bloc). En même temps je ne trouve pas cela très "space efficient" pour un soft de compression (un cheksum par bloc sur une archive de 10^6 blocs ça doit faire sont pesant d'octets   :Rolling Eyes:  ).

Et cette vérification du checksum ne peut pas être contournée ou supprimée sans risque pour l'intégrité du reste de l'archive ?

 *widan wrote:*   

>  *ghoti wrote:*   Mais si c'est simplement la moitié du quart d'un bit qui pose problème pour la décompression alors là les chances restent entières. Dans un fichier compressé un seul bit changé peut avoir beaucoup de conséquences. La compression bzip2 est faite par blocs. Normalement on peut récupérer tout les fichiers qui sont entièrement dans des blocs non concernés par l'erreur (en espérant que ça soit une erreur isolée et pas un disque plein de secteurs défectueux).

 C'est une erreur isolée dans le sens où je récupère déjà pas mal de fichiers avant qu'elle ne survienne.

Sachant que j'ai pu récupérer un hdd dispo et que je l'ai formaté et monté dans ma tour, j'ai un peu plus de liberté de mouvement.

Bon alors voici mon "plan d'actions" :

- je teste l'extraction avec le "--exclude", ça ne coute pas grand chose et on ne sait jamais (enfin amha l'erreur est sur la compression et pas sur le tar). Pour ça, un bunzip2 de mon archive ne devra pas me renvoyer d'erreur.

- si le bunzip2 me renvoie un message d'erreur, je tenterai bien l'argument "--force" : 

```
-f --force

    Forcer l'écrasement des fichiers en sortie. Normalement, bzip2 n'écrase pas les fichiers préexistants. Force également bzip2 à briser les liens matériels de fichiers, ce qu'il ne ferait pas autrement.

    bzip2 refuse normalement de décompacter des fichiers s'ils n'ont pas les octets d'en-tête magique corrects. S'il est forcé (-f), il traversera de tels fichiers sans les modifier. C'est la façon dont GNU gzip se comporte. 
```

Que pensez-vous de cette option ? Est-elle dangereuse pour mon système ? Est-ce que j'aurai un moyen de vérifier a postériori  les fichiers impactés ?

- si le "--force" ne fonctionne pas ou que vous me le déconseillez, je passerai au "bzip2recover". Mais n'ayant aucune expérience avec ce soft, voici comment j'opèrerai : 

```
bzip2recover the_bad_bad_backup.tar.bz2

bzip2 -t rec*the_bad_bad_backup.tar.bz2

rm rec_bad_blocs_of_the_bad_bad_backup.tar.bz2

bzip2 -dc rec*the_bad_bad_backup.tar.bz2 > the_good_parts_of_the_bad_bad_backup.tar

tar xvpf the_good_parts_of_the_bad_bad_backup.tar
```

Est-ce la bonne façon de procéder ??

Enjoy !

----------

## ghoti

 *yoyo wrote:*   

> - si le bunzip2 me renvoie un message d'erreur, je tenterai bien l'argument "--force" 

 

Je ne crois pas que ce soit d'un quelconque secours : "-f" concerne l'écrasement ou non d'un fichier existant au moment de la décompression et pas le skip d'un fichier mal comprimé !

 *Quote:*   

>        bzip2 and bunzip2 will by default not overwrite existing files.   If  you
> 
>        want this to happen, specify the -f flag.

 

----------

## yoyo

 *ghoti wrote:*   

> Je ne crois pas que ce soit d'un quelconque secours : "-f" concerne l'écrasement ou non d'un fichier existant au moment de la décompression et pas le skip d'un fichier mal comprimé !

 Mais la phrase qui suis dit bien :  *Quote:*   

> bzip2 refuse normalement de décompacter des fichiers s'ils n'ont pas les octets d'en-tête magique corrects. S'il est forcé (-f), il traversera de tels fichiers sans les modifier. C'est la façon dont GNU gzip se comporte.

 Ou alors je n'ai pas compris le sens de cette phrase (probabilité non négligeable) ...

----------

## ghoti

Je dois reconnaître que même le texte anglais n'est pas d'une clarté absolue   :Confused: 

 *Quote:*   

>              bzip2 normally declines to decompress files which don't  have  the
> 
>               correct magic header bytes.  If forced (-f), however, it will pass
> 
>               such files through unmodified.

 

Tel que je comprends l'histoire, si le fichier d'origine existe, bzip2 refuse de l'écraser, sauf si le "--force" est déclaré. Mais même dans ce cas, il faut aussi que les "magic header bytes" soient corrects, sinon il laisse tomber ("pass through")

Un truc à tester éventuellement : créer un fichier bidon portant le même nom que celui qui pose problème, histoire de voir la réaction   :Confused: 

----------

## widan

 *yoyo wrote:*   

> En même temps je ne trouve pas cela très "space efficient" pour un soft de compression (un cheksum par bloc sur une archive de 10^6 blocs ça doit faire sont pesant d'octets   )

 

Les blocs bzip2 sont bien plus gros que les secteurs d'un disque:

```
       -1 (or --fast) to -9 (or --best)

              Set the block size to 100 k, 200 k ..  900 k  when  compressing.

              Has  no effect when decompressing.  See MEMORY MANAGEMENT below.
```

 *yoyo wrote:*   

> - si le bunzip2 me renvoie un message d'erreur, je tenterai bien l'argument "--force" : 
> 
> ```
> -f --force
> 
> ...

 

Normalement tu ne peux pas décompresser des fichiers qui n'ont pas le "magic number" qui indique que ce sont des fichiers bzip2 (normal...), et dans ce cas tu as une erreur:

```
widan@phuket ~ $ bunzip2 -c /tmp/high.html

bunzip2: /tmp/high.html is not a bzip2 file.
```

Si tu rajoutes "-f", alors tu n'as pas d'erreur et bunzip2 renvoie le contenu du fichier source (sans décompression ou autres):

```
widan@phuket ~ $ bunzip2 -cf /tmp/high.html | head -n 2

<?xml version="1.0"?>

<?xml-stylesheet href="main.css" type="text/css"?>
```

Donc pas vraiment dangereux, mais pas très utile non plus.

----------

## Enlight

Toutes mes excuses, j'étais vraiment à la bourre aujourd'hui, mais si jamais quelqu'un se sent l'ame de coder, je vais détailler le mode opératoire que j'envisage.

1) extraire les 900 premiers kilos de l'archive (par prudence) et les garder de coté. On appelera ça le header par vulgarisation.

2) extraire un segment de l'archive et le concatener avec le header.

3) soumettre ça a bzip2recover (ça marche, j'ai testé)

3) parser le où les derniers rec* (ceux evetuellement contenus dans les 900ko du header vont se répéter, il faudra identifier combien cette section en contient) a la recherche des headers de tar (le formats ustar est documenté sur wikipedia et inclu même un checksum, par contre je ne connais pas encore les modalités de calcul)

4) lorsque le dernier fichier est tronqué on peut garder son descripteur tar

 et l'agréger avec le trun qui sera extrait par bzip2recover du prochain segment.

----------

## CryoGen

 *Enlight wrote:*   

> Toutes mes excuses, j'étais vraiment à la bourre aujourd'hui, mais si jamais quelqu'un se sent l'ame de coder, je vais détailler le mode opératoire que j'envisage.
> 
> 1) extraire les 900 premiers kilos de l'archive (par prudence) et les garder de coté. On appelera ça le header par vulgarisation.
> 
> 2) extraire un segment de l'archive et le concatener avec le header.
> ...

 

C'est beau :°)

----------

## dapsaille

 *ghoti wrote:*   

> Mais si c'est simplement la moitié du quart d'un bit qui pose problème pour la décompression alors là les chances restent entières.
> 
> Je maintiens ma proposition en croisant les doigts ... 
> 
> 

 

Mais ils sont tous devenus fous en mon absence ou quoi ?

A mon avis cette histoire sens le paté :/

----------

## yoyo

Bon, alors voila des nouvelles du front.

L'extraction avec le "--force" ne passe pas.

Je lance donc un bzip2recover gentoo.tar.bz2 et me retouve avec 5451 fichiers tar.bz2.

Je fais suivre tout ça d'un bzip2 -t rec*gentoo.tar.bz2 : aucun message d'erreur !   :Shocked: 

Qu'à cela ne tienne, bunzip2 gentoo.tar.bz2. Mais là : 

```
 bunzip2 gentoo.tar.bz2

bunzip2: Compressed file ends unexpectedly;

        perhaps it is corrupted?  *Possible* reason follows.

bunzip2: No such file or directory

        Input file = gentoo.tar.bz2, output file = gentoo.tar

It is possible that the compressed file(s) have become corrupted.

You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover

data from undamaged sections of corrupted files.

bunzip2: Deleting output file gentoo.tar, if it exists.
```

Alors là je ne comprends plus ...   :Confused: 

Je vais tenter l'argument "-tvv" mais bon, si vous avez une idée ?

----------

## widan

 *yoyo wrote:*   

> Je fais suivre tout ça d'un bzip2 -t rec*gentoo.tar.bz2 : aucun message d'erreur !  

 

Ca c'est normal je pense, bzip2recover a probablement ignoré les blocs abîmés, et les morceaux qu'il te donne sont juste les blocs corrects.

----------

## Mickael

 *widan wrote:*   

>  *yoyo wrote:*   Je fais suivre tout ça d'un bzip2 -t rec*gentoo.tar.bz2 : aucun message d'erreur !   
> 
> Ca c'est normal je pense, bzip2recover a probablement ignoré les blocs abîmés, et les morceaux qu'il te donne sont juste les blocs corrects.

 

+1

La doc semble dire cela :  *Quote:*   

> bzip2recover is a simple program whose purpose is to search for blocks in .bz2 files, and write each block out into its own .bz2 file. You can then use bzip2 -t to test the integrity of the resulting files, and decompress those which are undamaged.

 

Donc tu peux décompresser chacun des fichiers non endommagés qui te sont donnés par la sortie de l'option test par bunzip2 -cd, comme tu l'avais dit d'ailleurs plus haut. <---edit

----------

## yoyo

 *widan wrote:*   

>  *yoyo wrote:*   Je fais suivre tout ça d'un bzip2 -t rec*gentoo.tar.bz2 : aucun message d'erreur !   
> 
> Ca c'est normal je pense, bzip2recover a probablement ignoré les blocs abîmés, et les morceaux qu'il te donne sont juste les blocs corrects.

 -1

Car normalement, d'après le lien mis dans mon premier post : *Quote:*   

> 
> 
> % bunzip2 rec*bz2
> 
> bunzip2 stops when it finds the first (and hopefully last) corrupted file, which is exactly what I wanted to know.

 donc le test ne devrait pas passer.

Enfin, le "bunzip2 -cd rec*gentoo.tar.bz2 > backup.tar" est passé sans problème mais (hé oui   :Crying or Very sad:  ) le "tar xcvf backup.tar" qui a suivi a produit un grand nombre d'erreurs. Et curieusement, lorsque j'exclue le fichier/dossier incriminé, c'est le précédent qui n'est plus bon ...

Du coup j'ai tout "nettoyé" et je tente la méthode donnée en lien, à savoir "bzip2recover" suivi directement d'un "bunzip2 rec*bz2" pour trouver le fichier corrompu.

La suite au prochain épisode.

----------

## yoyo

 *yoyo wrote:*   

>  *Quote:*    % bunzip2 rec*bz2
> 
> bunzip2 stops when it finds the first (and hopefully last) corrupted file, which is exactly what I wanted to know. donc le test ne devrait pas passer.

 Et bien il est passé sans aucun problème ...   :Shocked: 

Je me dis de plus en plus que c'est l'archive "tar" et pas la compression qui a foirée.

Ou je n'ai pas compris le fonctionnement de bzip2recover ... J'ai la désagréable impression de tourner en rond.   :Evil or Very Mad: 

Bon, j'édite mon post : cette fois le doute n'est plus permis :

```
bunzip2 -vv gentoo.tar.bz2

    [snip]

    [5450: huff+mtf rt+rld]

    [5451: huff+mtf rt+rld]

    [5452: huff+mtf

bunzip2: Compressed file ends unexpectedly;

        perhaps it is corrupted?  *Possible* reason follows.

bunzip2: No such file or directory

        Input file = gentoo.tar.bz2, output file = gentoo.tar

It is possible that the compressed file(s) have become corrupted.

You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover

data from undamaged sections of corrupted files.

bunzip2: Deleting output file gentoo.tar, if it exists.
```

C'est donc bien la compression qui est corrompue.

Et si j'ai tout bien suivi, au bloc numéro 5452. Ok, alors je repasse un coup de bzip2recover. Mais avant, un petit "bunzip2 -tvv gentoo.tar.bz2" pour voir.

EDIT bis : bien, le "bunzip2 -tvv gentoo.tar.bz2" confirme le numéro de bloc corrompu, à savoir le 5452. C'est l'heure du "bzip2recover".

EDIT ter : DIANTRE !!

Le "bzip2recover" s'arrête au bloc 5451.   :Shocked: 

Bon par acquis de conscience, je contrôle les tailles (en blocks "pleins") :

```
ls --hide=rec*

gentoo.tar.bz2  rescue.txt

du -sb --exclude=gentoo.tar.bz2 --exclude=rescue.txt

4294700647      .

du -b gentoo.tar.bz2

4294967295      gentoo.tar.bz2
```

Il y a donc des blocs qui ne sont pas restaurés par "bzip2recover" ???

Comment est-ce possible ?? D'après le lien dans mon premier post, "bzip2recover" se contente d'extraire les blocs du bzip2 sur le fichier complète, sans faire aucune vérification.   :Confused: 

Voila la sortie de "bzip2recover" : 

```
   block 5449 runs from 34333664260 to 34340842514

   block 5450 runs from 34340842563 to 34348017788

   block 5451 runs from 34348017837 to 34355206589

   block 5452 runs from 34355206638 to 34359738360 (incomplete)

bzip2recover: splitting into blocks

   writing block 1 to `rec00001gentoo.tar.bz2' ...

   writing block 2 to `rec00002gentoo.tar.bz2' ...

   writing block 3 to `rec00003gentoo.tar.bz2' ...

   writing block 4 to `rec00004gentoo.tar.bz2' ...

[snip]

   writing block 5449 to `rec05449gentoo.tar.bz2' ...

   writing block 5450 to `rec05450gentoo.tar.bz2' ...

   writing block 5451 to `rec05451gentoo.tar.bz2' ...

bzip2recover: finished
```

----------

## Enlight

du rapide pour pas changer, mais j'explique juste :

tar.bz2 endommagé -> bzip2recover -> plusieurs morceaux d'archives tar a détarrer (splitter), la partie bz2 est déjà décompressée.

edit :

le tar c'est une agrégation genre [[description fichier 1][fichier 1 en clair][description fichier2][fichier2 en clair]...]

----------

## widan

 *yoyo wrote:*   

> Bon par acquis de conscience, je contrôle les tailles (en blocks "pleins") :
> 
> ```
> du -b gentoo.tar.bz2
> 
> ...

 

Euh... 4294967295 = 0xffffffff. Pas bon signe ça...

 *yoyo wrote:*   

> Voila la sortie de "bzip2recover" :
> 
> ```
>    block 5449 runs from 34333664260 to 34340842514
> 
> ...

 

Le dernier bloc (incomplet) s'arrête au bit 34359738360, ce qui correspond à l'octet 4294967295. Ca correspond à la taille de ton fichier. Le fichier est tronqué, pas corrompu.

----------

## yoyo

 *Enlight wrote:*   

> tar.bz2 endommagé -> bzip2recover -> plusieurs morceaux d'archives tar a détarrer (splitter), la partie bz2 est déjà décompressée.

 Je ne crois pas que bzip2recover décompresse quelque chose;amha il se contente de découper le fichier compressé (archive tar ou pas) en autant de blocs compressés qu'il en trouve dans ce fichier.

 *widan wrote:*   

> Euh... 4294967295 = 0xffffffff. Pas bon signe ça...

 Tu peux détaillé un peu plus stp ?

 *widan wrote:*   

> Le dernier bloc (incomplet) s'arrête au bit 34359738360, ce qui correspond à l'octet 4294967295. Ca correspond à la taille de ton fichier. Le fichier est tronqué, pas corrompu.

 Tronqué ? Comment ça ? Tu veux dire que bzip2recover s'arrête à ce bloc même s'il reste encore d'autres blocs suivants dans le fichier ?

----------

## widan

 *yoyo wrote:*   

>  *widan wrote:*   Euh... 4294967295 = 0xffffffff. Pas bon signe ça... Tu peux détaillé un peu plus stp ?

 

C'est la valeur maximale d'un entier 32 bits non signé. Généralement quand on voit ce genre de nombre c'est pas vraiment bon signe car ça peut vouloir dire qu'il y a eu un dépassement de capacité d'une variable et qu'elle est repassée à 0, ce qui peut produire un comportement... bizarre.

Dans ton cas, il y a peut être quelque chose qui n'a pas géré correctement le fichier de plus de 4Go et qui l'a tronqué à la valeur limite.

 *yoyo wrote:*   

> Tronqué ? Comment ça ? Tu veux dire que bzip2recover s'arrête à ce bloc même s'il reste encore d'autres blocs suivants dans le fichier ?

 

Il n'y a pas de suivants. Ton fichier fait exactement 4Go, et se termine sur un bloc incomplet. Il manque la fin du fichier.

----------

## Ey

Oui ca ressemble au fichier qui a transité sur un fs qui ne supporte pas les fichiers de plus de 4Gigs...

----------

## Enlight

 *Ey wrote:*   

> Oui ca ressemble au fichier qui a transité sur un fs qui ne supporte pas les fichiers de plus de 4Gigs...

 

++

----------

## yoyo

Bon en voyant ça vendredi (ou samedi) *widan wrote:*   

> Il n'y a pas de suivants. Ton fichier fait exactement 4Go, et se termine sur un bloc incomplet. Il manque la fin du fichier.

 j'ai eu un flash !

J'ai appelé un grand sorcier marabout qui m'a exorcisé par deux claques dans la tronche !! Alpha est sorti de mon cerveau et il a pu reprendre une activité normale.

Effectivement j'ai déplacé mon archive sur une partition en vfat. A force d'utiliser des fs performants j'en ai oublié les limitations des vieux fs à billou.   :Embarassed: 

Bon, la réinstallation est en cours (  :Rolling Eyes:  ); dans mon malheur j'ai quand même conservé mon "/etc" et la quasi totalité de mon "/home", c'est déjà ça ...

Merci à tous d'avoir consacré du temps à ce problème qui n'en était finalement pas un.

PS : j'ai configuré iptable pour refuser l'accès alpha, ce genre de chose ne devrait plus se reproduire à l'avenir (du moins j'espère qu'il n'y a pas un "rootkit" qui traine   :Razz:  ).

----------

## dapsaille

Yoyo ... tu n'utilise pas ntfs3g ou encore mieux ext2 driver pour windows ? 

 Navré pour ton backup :/

----------

## yoyo

 *dapsaille wrote:*   

> Yoyo ... tu n'utilise pas ntfs3g ou encore mieux ext2 driver pour windows ? 

 Je n'avais pas le support "fuse" dans mon noyau précédent et je n'avais pas pris le temps de convertir ma partition d'échange en ext2 (bien que j'ai installé le driver windows depuis bien longtemps).

Enfin pour cette partition d'échange, il va vraiment falloir que je contrôle ma sauvegarde avant de refaire ce genre de "blague" parce que c'est là où se trouve mes données "sensibles".   :Rolling Eyes: 

Enjoy !

----------

## truc

En tous cas cette petite 'blague' comme tu dis, à motivé des gens, et c'était très interessant  :Smile:  (même si beaucoup de chose m'ont échappée...)

Bon, bah alors, c'est quoi la conclusion, résolu=> ne (plus) jamais utiliser ce genre de FS alternatifs qu'est, par exemple, le vfat (on dit FAT peut-être?) pour faire ses backups  :Razz:   :Question: 

----------

## yoyo

 *truc wrote:*   

> Bon, bah alors, c'est quoi la conclusion, résolu=> ne (plus) jamais utiliser ce genre de FS alternatifs qu'est, par exemple, le vfat (on dit FAT peut-être?) pour faire ses backups  

 En effet, je ne sais pas trop quoi mettre dans le titre; le problème n'est pas solvable à cause du fs (fat correspond à l'ancêtre du fat32) et surtout (comme dans 99% des cas) à cause de l'interface chaise-clavier.

Tiens, d'ailleurs ça me donne une idée pour le titre ...   :Rolling Eyes: 

----------

## CryoGen

arf  :Very Happy: 

/me a sa partition d'échange en ext3  :Smile: 

----------

