10.12 Sierra Disque dur externe crypté reformaté

Là je pense qu'on est bon dans le compte.

On va dans la foulée recréer la partition du booter3 - histoire de vérifier ce qui se passe...

Passe le lot de commandes :
Bloc de code:
diskutil umount force disk8
diskutil umountDisk force disk5
sudo gpt add -b 5860270980 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC -i 7 disk5

  • qui démonte les disques > puis crée un descripteur de partition de rang 7 > dans le type "Apple_Boot" > avec le bloc n° 5860270980 en bloc 0 > et une extension de 262144 = 134,2 Go

Si tu obtiens bien un :
Bloc de code:
disk5s7 added
  • poste les tableaux retournés par les 2 commandes :
Bloc de code:
diskutil list
sudo gpt show disk5
 
Bloc de code:
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:          Apple_CoreStorage Sans titre              1.4 TB     disk5s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk5s3
   4:          Apple_CoreStorage RAID HANGAR 1           605.0 GB   disk5s4
   5:                 Apple_Boot                         134.2 MB   disk5s5
   6:          Apple_CoreStorage                         999.7 GB   disk5s6
   7:                 Apple_Boot                         134.2 MB   disk5s7

/dev/disk6 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS HANGAR 1               +1.0 TB     disk6
                                 Logical Volume on disk1s5
                                 727642FC-C67B-434A-868E-C536E6CA86BC
                                 Unlocked Encrypted

/dev/disk7 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS HANGAR 2               +839.4 GB   disk7
                                 Logical Volume on disk1s3
                                 82916BFC-309D-4312-8A8D-A2F12F4406CE
                                 Unlocked Encrypted

Offline
                                 Logical Volume RAID HANGAR 1 on disk5s4
                                 F8FA9EB4-9508-4AE6-833A-3C5FCD55FD4E
                                 Locked Encrypted
Bloc de code:
sudo gpt show disk5
       start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6        
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640  2725095696      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  2725505336      262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  2725767480  1181640636      4  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  3907408116      262144      5  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  3907670260  1952600720      6  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  5860270980      262144      7  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  5860533124           7        
  5860533131          32         Sec GPT table
  5860533163           1         Sec GPT header
 
On a bien les 7 blocs libres entre le pied de la dernière partition et le début de la sauvegarde de la GPT comme requis.

Tout tombe juste numériquement parlant > mais -->

- la partition du dernier booter ne montre pas de volume Boot OS X => son bloc 0 n'a pas récupéré le super-bloc du système de fichiers jhfs+ de la partition originelle. Lequel devrait se situer plus haut sur les blocs.​

- la partition CoreStorage3 ne montre pas non plus de label de Conteneur > et n'exporte pas de Logical Volume => son bloc 0 n'a pas non plus récupéré le super-bloc du système de fichiers jhfs+ de la partition originelle. Lequel devrait se situer plus bas sur les blocs.​

Le miracle ne s'est produit que pour la partition médiane. Passe le lot de commandes :
Bloc de code:
diskutil umount force disk8
diskutil umountDisk force disk5
diskutil repairDisk disk5

  • qui démonte les disques > puis répare la table de partition > les booters > les architectures CoreStorage

Poste l'affichage retourné.
 
Bloc de code:
 repairDisk disk5
Repairing the partition map might erase disk5s1, proceed? (y/N) y
Started partition map repair on disk5
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking booter partition disk5s3
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Boot OS X appears to be OK
File system check exit code is 0
Checking booter partition disk5s5
Updating boot support partitions for the volume as required
Checking booter partition disk5s7
Updating boot support partitions for the volume as required
Problems were encountered during repair of the partition map
Error: -69846: Unrecognized file system
 
Bloc de code:
 start        size  index  contents

          0           1         PMBR

          1           1         Pri GPT header

          2          32         Pri GPT table

          34           6         

          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B

      409640  2725095696      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC

  2725505336      262144      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

  2725767480  1181640636      4  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC

  3907408116      262144      5  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

  3907670260  1952600720      6  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC

  5860270980      262144      7  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

  5860533124           7         

  5860533131          32         Sec GPT table

  5860533163           1         Sec GPT header

APRÈS

Bloc de code:
/dev/disk5 (external, physical):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:      GUID_partition_scheme                        *3.0 TB     disk5

   1:                        EFI EFI                     209.7 MB   disk5s1

   2:          Apple_CoreStorage Sans titre              1.4 TB     disk5s2

   3:                 Apple_Boot Boot OS X               134.2 MB   disk5s3

   4:          Apple_CoreStorage RAID HANGAR 1           605.0 GB   disk5s4

   5:                 Apple_Boot                         134.2 MB   disk5s5

   6:          Apple_CoreStorage                         999.7 GB   disk5s6

   7:                 Apple_Boot                         134.2 MB   disk5s7


/dev/disk6 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                  Apple_HFS HANGAR 1               +1.0 TB     disk6

                                Logical Volume on disk1s5

                                727642FC-C67B-434A-868E-C536E6CA86BC

                                Unlocked Encrypted


/dev/disk7 (internal, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                  Apple_HFS HANGAR 2               +839.4 GB   disk7

                                Logical Volume on disk1s3

                                82916BFC-309D-4312-8A8D-A2F12F4406CE

                                Unlocked Encrypted


/dev/disk8 (external, virtual):

   #:                       TYPE NAME                    SIZE       IDENTIFIER

   0:                  Apple_HFS RAID HANGAR 1          +604.5 GB   disk8

                                Logical Volume on disk5s4

                                F8FA9EB4-9508-4AE6-833A-3C5FCD55FD4E

                                Unlocked Encrypted
 
Reposte le tableau de la commande :
Bloc de code:
diskutil list

  • pour voir s'il y a eu un changement...
 
Aucun changement. Comme il commence à se faire tard --> je jette l'éponge pour cette fois.

- je reviendrai te dire si j'aperçois des possibilités "rationnelles" d'autres manipulations.​
 
  • J’aime
Réactions: Mc kintosh
Entendu merci pour encore pour ton aide. C'est vexant. Pourtant la partition 3 aurait dû être la plus éloignée c'est celle que j'ai du créé en dernier dans la logique.
 
Je ne disposais au départ que de cette bande de blocs libres continue de fin de disque -->
Bloc de code:
  3907670260  1952862871

  • avec l'idée directrice que 2 partitions devaient se partager cet espace : une partition de type "Apple_CoreStorage" et une partition de type "Apple_Boot". Avec l'assurance qu'une partition de type "Apple_Boot" doit avoir exactement une extension de 262144 blocs = 134,2 Mo. Avec l'assurance supplémentaire qu'aucun bloc libre ne doit séparer la partition booter de sa partition CoreStorage de référence.
  • en supposant que la partition booter s'arrêtait à 7 blocs libres du 1er bloc de sauvegarde de la GPT de queue de disque > on avait donc le dernier bloc de la partition booter. Et 262144 blocs plus haut son 1er bloc. Donc un bloc plus haut le dernier bloc de la partition CoreStorage.
  • mais ce découpage théorique bute sur un problème : rien n'oblige jamais une partition principale à commencer au 1er bloc libre suivant le dernier bloc de la partition précédente. Il y a fréquemment des zones tampons de milliers de blocs libres (de 512 octets de taille standard) entre la fin d'une partition et le départ d'une autre partition principale (à l'exception donc des partitions auxiliaires toujours accollées sans bloc libre de séparation à leur partition de référence).
  • ma commande de création d'un descripteur de partition CoreStorage6 --> a assigné en bloc 0 de cette partition le 1er bloc libre après le dernier de la partition booter5 au-dessus. J'espérais ce faisant que > comme ça a marché pour la partition CoreStorage4 du milieu > récupérer en 1er bloc (bloc 0) de la partition créée le "super-bloc" portant l'inscription du header (en-tête) du système de fichiers de la partition disparue. Header d'un système de fichiers jhfs+ standard > le reste du système de fichiers sur les blocs suivants > les headers de l'architecture CoreStorage s'insérant encore après cette inscription primaire. Ce > dans le cas de figure où la partition aurait été créée au départ en format jhfs+ classique > puis convertie à un système de stockage CoreStorage ; au lieu d'être créée d'entrée dans le format princeps CoreStorage. Auquel cas le header du CoreStorage occupe le "super-bloc" > le système de fichiers jhfs+ ne s'incrivant qu'après. Ces interversions d'inscriptions permettant une réversibilité du CoreStorage (1er cas de figure) > ou une irréversibilité du CoreStorage (2è cas de figure).

=> bref le problème est : où donc est le "super-bloc" (= bloc origine du système de fichiers) de la partition CoreStorage du bas de disque ? - on sait désormais (science négative décevante) qu'il n'est pas le bloc n° 3907670260 du disque (1er bloc libre après la partition booter du dessus).

----------
 
Quelqu'un qui aurait une patience énorme (ou des talents de programmation que je n'ai pas) --> pourrait s'amuser à créer n descripteurs de partition de type CoreStorage6 en décalant chaque fois le bloc 0 de cette partition d'un bloc après le bloc n° 3907670260 invalide (et en rétrécissant chaque fois d'un bloc l'extension de la partition à créer > pour qu'une partition booter d'une taille fixe de 262144 blocs puisse toujours occuper une position de queue de disque s'arrêtant à 7 blocs libres de la sauvegarde de la GPT. En vérifiant après chaque création de partition > si une régénération de Conteneur CoreStorage n'a pas eu lieu > par récupération en bloc 0 du "super-bloc" du système de fichiers la partition disparue.

La tâche n'a rien d'infini > car les tampons d'espace libre entre 2 partitions n'atteignent jamais 30 000 blocs en extension. Il y a aurait donc au maximum moins de 30 000 essais de créations de descripteurs de partition à tester. Mais ce nombre excède ma capacité tierce d'intervention.

----------

Il y aurait une alternative "analogique". Tu as d'autres DDE de grande taille avec des partitions chiffrées. Il faudrait que tu passes 2 commandes :
Bloc de code:
diskutil list diskx
sudo gpt show diskx

  • x serait l'index de disque d'un autre DDE à partitions chiffrées

=> et que tu postes les 2 tableaux --> afin que je voie s'il existe des tampons de blocs libres entre les partitions et de quelle extension. Si le nombre du blocs du tampon est conforme à un défaut ou aléatoire. Pour voir s'il serait possible de transposer une valeur à ton disque.

----------

S'il existait des logiciels de récupération > qui seraient capables > après scan des blocs d'un disque > de pointer précisément les numéros de blocs de "super-blocs" (blocs origines de systèmes de fichiers) détectés --> alors le problème serait réglé.

Je ne pense pas que détecter une écriture de bloc comme se singularisant par un statut de "header" de système de fichiers > ce qui fait que ledit bloc serait un "super-bloc" --> soit impossible à un programme de récupération de données. Mais il paraît que cette simple question n'ait pas effleuré l'esprit des concepteurs de ces logiciels.

----------
 
Dernière édition par un modérateur:
Il y a néanmoins un facteur qui perturbe la problématique restreinte de mes messages ci-dessus. C'est cette description de partition -->
Bloc de code:
   5:                 Apple_Boot                         134.2 MB   disk5s5

  • il s'agit du second booter sur le disque. Ce qui est caractéristique est qu'aucun nom de volume ne soit assigné à cette partition. Partition vide de système de fichiers jhfs+. Signe que le bloc 0 de cette partition n'a pas récupéré le "super-bloc" du jhfs+ de la partition booter antérieure.
  • or : la partition du dessus (CoreStorage) elle --> possède son "exacte" délimitation. La preuve : il y a eu régénération de l'architecture CoreStorage et remontage du volume terminal. La partition booter devant coller cette partition de référence sans bloc libre > et devant avoir une extension exacte de 262144 blocs --> la localisation aurait dû pile récupérer en bloc 0 le super-bloc de l'ancienne partition booter.
  • comment est-il possible qu'il y ait échec sur cette partition-booter ? - voici la conjecture que je forme : à condition que le 1er bloc d'une partition récupère bien le super-bloc d'un système de fichiers --> une variation illégitime d'extension de la partition définie par le descripteur est susceptible d'être "admise" par le système de fichiers générateur du volume. Ce > au prix d'une "erreur locale" et pas d'une "erreur globale". Un système de fichiers, en effet, inclut un gestionnaire de l'allocation de blocs qu'on appellera pour généraliser le "spaceman" : le "space_manager" ou gérant des blocs. Un système de fichiers peut > en tant que structure globale --> générer un volume montable > ce sur une extension de blocs non conforme à l'extension enregistrée localement par le spaceman. Donc le système de fichiers peut "outrepasser" (over-ride) une erreur locale du spaceman (décalage entre l'extension de blocs attendue pour la partition et l'extension trouvée) --> pour régénérer un volume de fichiers sur une "extension illégitime".
  • il faudrait donc que je suppose que > le volume RAID HANGAR 1 bien régénéré sur la partition médiane --> ne valide pas exactement en extension ladite partition du seul fait d'exister en tant que volume monté. Il y a peut-être moyen de vérifier cette conjecture : c'est de passer des commandes de vérification de l'architecture CoreStorage et du système de fichiers jhfs+ porté --> afin de voir si une taille légitime de la partition attendue ne serait pas alléguée > ne correspondant pas à son actuelle extension en nombre de blocs. Cette inspection m'intéresse fort > à bien y réfléchir.

Si le disque du DDE est toujours disk5 > et le Logical Volume CoreStorage portant le volume RAID HANGAR 1 toujours disk8 --> passe les commandes :
Bloc de code:
diskutil info disk8
diskutil cs list
df -H /Volumes/"RAID HANGAR 1"
diskutil verifyVolume disk8

  • poste tous les tableaux retournés.

Note : parmi ces commandes > la commande df est possiblement la plus pertinente > car elle adresse toujours le spaceman d'un système de fichiers --> pour lui emprunter ses mesures propres : extension totale des blocs > blocs occupés > blocs disponibles.
 
Dernière édition par un modérateur:
Pour ce que tu dis, j'ai deux logiciels complet : StellarPhoenix avec un outil de réparation, et DiskDrill. J'ai aussi TestDisk et Photorec que j'ai utilisé sur d'autres disques pour essayer (en vain ) de récupérer les photos qui auraient pu y être copiées.


Bloc de code:
/dev/disk7 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk7
   1:                        EFI EFI                     209.7 MB   disk7s1
   2:          Apple_CoreStorage Sans titre              1.4 TB     disk7s2
   3:                 Apple_Boot Boot OS X               134.2 MB   disk7s3
   4:          Apple_CoreStorage RAID HANGAR 1           605.0 GB   disk7s4
   5:                 Apple_Boot                         134.2 MB   disk7s5
   6:          Apple_CoreStorage                         999.7 GB   disk7s6
   7:                 Apple_Boot                         134.2 MB   disk7s7

/dev/disk8 (external, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS RAID HANGAR 1          +604.5 GB   disk8
                                 Logical Volume on disk7s4
                                 F8FA9EB4-9508-4AE6-833A-3C5FCD55FD4E
                                 Unlocked Encrypted

Bloc de code:
+-- Logical Volume Group 9EE60ADE-712E-42D9-A5E6-95A754128064
|   =========================================================
|   Name:         Sans titre
|   Status:       Offline
|   Size:         0 B (0 B)
|   Free Space:   -none-
|   |
|   +-< Physical Volume CD903024-727F-421C-A8BA-8AB3DE625A2A
|       ----------------------------------------------------
|       Index:    0
|       Disk:     disk7s2
|       Status:   Checking
|       Size:     1395248996352 B (1.4 TB)
|
+-- Logical Volume Group 0BCEEC1F-6FF9-46E6-A455-26E34423C142
    =========================================================
    Name:         RAID HANGAR 1
    Status:       Online
    Size:         605000005632 B (605.0 GB)
    Free Space:   147808256 B (147.8 MB)
    |
    +-< Physical Volume 1F2E452A-4691-4B88-A920-7B696837ABE9
    |   ----------------------------------------------------
    |   Index:    0
    |   Disk:     disk7s4
    |   Status:   Online
    |   Size:     605000003584 B (605.0 GB)
    |
    +-> Logical Volume Family F9561CE5-A40A-497B-9446-B78576BCB766
        ----------------------------------------------------------
        Encryption Type:         AES-XTS
        Encryption Status:       Unlocked
        Conversion Status:       Complete
        High Level Queries:      Fully Secure
        |                        Passphrase Required
        |                        Accepts New Users
        |                        Has Visible Users
        |                        Has Volume Key
        |
        +-> Logical Volume F8FA9EB4-9508-4AE6-833A-3C5FCD55FD4E
            ---------------------------------------------------
            Disk:                  disk8
            Status:                Online
            Size (Total):          604499869696 B (604.5 GB)
            Revertible:            No
            LV Name:               RAID HANGAR 1
            Volume Name:           RAID HANGAR 1
            Content Hint:          Apple_HFS

Bloc de code:
df -H /Volumes/"RAID HANGAR 1"
Filesystem   Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk8   604G   604G    38M   100% 2403050 4292564229    0%   /Volumes/RAID HANGAR 1
 
Bloc de code:
diskutil verifyVolume disk8
Started file system verification on disk8 RAID HANGAR 1
Verifying storage system
Checking volume
disk7s4: Scan for Volume Headers
Invalid Volume Header @ 605000005120: unsupported format
disk7s4: Scan for Disk Labels
Logical Volume Group 0BCEEC1F-6FF9-46E6-A455-26E34423C142 on 1 device
disk7s4: Scan for Metadata Volume
Logical Volume Group has a 24 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify F9561CE5-A40A-497B-9446-B78576BCB766
Load and verify F8FA9EB4-9508-4AE6-833A-3C5FCD55FD4E
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 0BCEEC1F-6FF9-46E6-A455-26E34423C142 appears to be OK
Storage system check exit code is 0
Verifying file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume RAID HANGAR 1 appears to be OK
File system check exit code is 0
Finished file system verification on disk8 RAID HANGAR 1
 
Les tableaux retournés par les commandes --> ne révèlent pas d'information décisive sur une taille de partition qui serait inadéquate. Piste qui tourne court.
 
Voici le disque dur de 2To qui contenait les archives et le boulot. J'avais chiffré à l'identique les en trois partitions (+ 1 de 128G pour sauvegarder le disque ssd de démarrage)

Voilà ce que ça donne

Bloc de code:
 #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS WESTMERE SOS            111.6 GB   disk2s2
   3:          Apple_CoreStorage Sans titre              839.8 GB   disk2s3
   4:                 Apple_Boot Boot OS X               134.2 MB   disk2s4
   5:          Apple_CoreStorage HANGAR 1                1.0 TB     disk2s5
   6:                 Apple_Boot Boot OS X               134.2 MB   disk2s6

Bloc de code:
 sudo gpt show disk5
       start        size  index  contents
           0  2047049728

Bloc de code:
 sudo gpt show disk6
start        size  index  contents
           0  1639514112
 
Dernière édition:
Poste le tableau retourné par la commande :
Bloc de code:
sudo gpt show disk2

  • que je voie si des tampons d'espace libre séparent des partitions
----------

Question : comment t'y prends-tu pour partitionner / chiffrer ? --> tu partitionnes d'abord avec des formats jhfs+ standards > puis tu vires au chiffrement > ce qui génère un CoreStorage ? - ou tu crées d'entrée des partitions chiffrées ? - le CoreStorage qui porte le volume RAID HANGAR 1 est déclaré : "irréversible" (à un format jhfs+ simple) : signe que la partition a été créée chiffrée et pas convertie ensuite.
 
Bloc de code:
 start        size  index  contents
           0           1         PMBR
           1           1         Pri GPT header
           2          32         Pri GPT table
          34           6        
          40      409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409640        2008        
      411648   217889176      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
   218300824      262144        
   218562968  1640203880      3  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  1858766848      262144      4  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  1859028992  2047737992      5  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  3906766984      262144      6  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  3907029128           7        
  3907029135          32         Sec GPT table
  3907029167           1         Sec GPT header
 
Cette partition-ci -->
Bloc de code:
   2:                  Apple_HFS WESTMERE SOS            111.6 GB   disk2s2

  • est suivie par une bande de blocs libres de 262144 blocs (= 134,2 Mo) : la taille d'une partition booter supprimée. On peut supposer que la partition WESTMERE SOS ait été chiffrée > puis reconvertie à un format standard - le booter supprimé mais son espace non récupéré.

Bref : aucun enseignement à tirer > sinon que les partitions chiffrées et leurs auxiliaires se suivent sans blocs libres intercalaires > ce jusqu'à une marque de 7 blocs libres avant la sauvegarde de la GPT. Exactement le scénario adopté pour ton autre DDE.
 
Et ta solution de tester bloc par bloc quelle serait-elle ? Peu importe le temps que ça prendra si j'ai l'espoir de récupérer les données.