Problème de clé USB

Dom44

Membre actif
20 Mai 2010
110
3
Région nantaise
Parti en voyage pendant un mois avec une clé USB Verbatim 32 GO qui marchait fort bien à la maison, tant avec mon iMac qu'avec mon MBP, j'ai eu la surprise de découvrir un soir, en la connectant à mon MBP, qu'elle n'était plus reconnue. J'ai sauvegardé dessus plein d'informations et j'aimerais les récupérer... Comment faire puisqu'aucun de mes Mac n'accepte de la reconnaître et préconise de l'initialiser ? Merci d'avance de l'aide que vous pourrez m'apporter.
Pour info, le MBP est sous Capitan, et j'ai un iMac sous Capitan, l'autre sous Sierra...
 
Salut

Clé usb branchée, que renvoie dans le terminal (Applications/Utilitaires/Terminal) la commande :
diskutil list
Il vaut mieux donner les résultats par copier/coller texte.
 
Désolé, mais j'avais du m'absenter et n'ai pas pu répondre plus tôt. Dès que je branche la clé, un affichage m'indique que
"Le disque que vous avez inséré n’est pas lisible par cet ordinateur"... et me propose de l'initialiser, l'éjecter ou l'ignorer... En ignorant l'offre, Utilitaires disk ne voit pas le disque initialement, puis en le réinsérant, m'offre de l'initialiser ! Mais impossible d'accéder aux dossiers qui sont enregistrés dessus.
 
Désolé, mais j'avais du m'absenter et n'ai pas pu répondre plus tôt. Dès que je branche la clé, un affichage m'indique que
"Le disque que vous avez inséré n’est pas lisible par cet ordinateur"... et me propose de l'initialiser, l'éjecter ou l'ignorer... En ignorant l'offre, Utilitaires disk ne voit pas le disque initialement, puis en le réinsérant, m'offre de l'initialiser ! Mais impossible d'accéder aux dossiers qui sont enregistrés dessus.
Et que dit un
diskutil list
;)
 
la commande est à lancer dans le Terminal (dans Applications/Utilitaires),
ou en tapant terminal dans Spotlight pour le démarrer.
 
Par ailleurs, en fouillant un peu plus avec Utilitaires de disques, j'obtiens "emplacement : externe, connexion USB, table de partition non géré, État S.M.A.R.T. non géré, capacité 31,46 Go, type Disk, appareil Disk5... et toujours la proposition de l'initialiser !
 
J'ai donné ci-dessus la réponse par copier/coller... et il n'y a vraiment rien d'autre que ce qui suit :
/dev/disk5 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: *31.5 GB disk5
 
Salut Dom

Pour t'aider à faire la comparaison, voici le résultat de la commande diskutil list concernant une clé USB de 15 Go dont le volume s'intitule CLE (j'ai édité le n° de disque à disk5 pour qu'il corresponde avec celui de ta clé) :
Bloc de code:
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *15.7 GB    disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:                  Apple_HFS CLE                     15.4 GB    disk5s2

Si je mets en relation le retour concernant ta clé :
Bloc de code:
/dev/disk5 (external, physical):
   #:                      TYPE NAME                     SIZE       IDENTIFIER
   0:                                                   *31.5 GB    disk5

voici ce qui ressort :

- aucune table de partition n'est reconnue sur la ligne 0 qui désigne le secteur d'amorçage du disque : ni une GUID_partition_scheme (GPT), ni une FDisk_partition_scheme (MBR) ;

- par voie de conséquence > aucune partition n'est identifiée, porteuse d'un système de fichiers capable de monter un volume affichant des fichiers lisibles.​

=> c'est la raison pour laquelle tu obtiens le message du Finder : "le disque que vous avez inséré n'est pas lisible par cet ordinateur" > il n'est pas lisible, pas parce qu'il porte des écritures illisibles, mais parce qu'il est sans écriture d'une table de partition > le disque apparaît alors comme « blank » : inamorçable = aucun descripteur d'une table de partition n'existe qui désignerait un espace de blocs adressable en lecture.

Je te propose une vérification supplémentaire. Ta clé attachée à ton Mac > repasse d'abord pour toi-même un :
Bloc de code:
diskutil list
afin de vérifier si le disque de ta clé est toujours identifié au rang 5 (= disk5 > si ce n'était pas le cas, remplace le 5 de mon disk5 dans la commande ci-dessous par le bon n°).

Passe à présent la commande (informative) :
Bloc de code:
sudo gpt show /dev/disk5
et ↩︎ (tu valides en pressant la touche "Entrée") --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎

Cette commande appelle l'utilitaire gpt (guid_partition_table_utility) avec le verbe show (montrer) sur la cible du disk5 dans le registre dev (des devices : appareils logiques) --> en retour, tu vas voir s'afficher le tableau de la distribution des blocs du disque de ta clé, avec désignation des tables de partitions (il peut y en avoir 2 parallèles) sur le secteur d'amorçage (tête) et le secteur de backup (queue) - si du moins des tables de partitions ou leurs traces résiduelles sont trouvées.

=> peux-tu poster ce tableau en copier-coller ici > pour vérifier l'étendue de la désolation ?
 
Salut Dom

Pour t'aider à faire la comparaison, voici le résultat de la commande diskutil list concernant une clé USB de 15 Go dont le volume s'intitule CLE (j'ai édité le n° de disque à disk5 pour qu'il corresponde avec celui de ta clé) :
Bloc de code:
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *15.7 GB    disk5
   1:                        EFI EFI                     209.7 MB   disk5s1
   2:                  Apple_HFS CLE                     15.4 GB    disk5s2

Si je mets en relation le retour concernant ta clé :
Bloc de code:
/dev/disk5 (external, physical):
   #:                      TYPE NAME                     SIZE       IDENTIFIER
   0:                                                   *31.5 GB    disk5

voici ce qui ressort :

- aucune table de partition n'est reconnue sur la ligne 0 qui désigne le secteur d'amorçage du disque : ni une GUID_partition_scheme (GPT), ni une FDisk_partition_scheme (MBR) ;

- par voie de conséquence > aucune partition n'est identifiée, porteuse d'un système de fichiers capable de monter un volume affichant des fichiers lisibles.​

=> c'est la raison pour laquelle tu obtiens le message du Finder : "le disque que vous avez inséré n'est pas lisible par cet ordinateur" > il n'est pas lisible, pas parce qu'il porte des écritures illisibles, mais parce qu'il est sans écriture d'une table de partition > le disque apparaît alors comme « blank » : inamorçable = aucun descripteur d'une table de partition n'existe qui désignerait un espace de blocs adressable en lecture.

Je te propose une vérification supplémentaire. Ta clé attachée à ton Mac > repasse d'abord pour toi-même un :
Bloc de code:
diskutil list
afin de vérifier si le disque de ta clé est toujours identifié au rang 5 (= disk5 > si ce n'était pas le cas, remplace le 5 de mon disk5 dans la commande ci-dessous par le bon n°).

Passe à présent la commande (informative) :
Bloc de code:
sudo gpt show /dev/disk5
et ↩︎ (tu valides en pressant la touche "Entrée") --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎

Cette commande appelle l'utilitaire gpt (guid_partition_table_utility) avec le verbe show (montrer) sur la cible du disk5 dans le registre dev (des devices : appareils logiques) --> en retour, tu vas voir s'afficher le tableau de la distribution des blocs du disque de ta clé, avec désignation des tables de partitions (il peut y en avoir 2 parallèles) sur le secteur d'amorçage (tête) et le secteur de backup (queue) - si du moins des tables de partitions ou leurs traces résiduelles sont trouvées.

=> peux-tu poster ce tableau en copier-coller ici > pour vérifier l'étendue de la désolation ?
La réponse après application des recommandations donne (avec disk7 car j'ai branché d'autres disques entre temps pour faire des copies de sauvegarde des autres clés... :

imac-de-lapeyre-2-1:~ lapeyredominique$ sudo gpt show /dev/disk7

Password:

start size index contents

0 61440000

imac-de-lapeyre-2-1:~ lapeyredominique$
 
Encore merci de ces explications fort bien détaillées. La réponse après application des recommandations donne (avec disk7 car j'ai branché d'autres disques entre temps pour faire des copies de sauvegarde des autres clés... :

dev/disk7 (external, physical):

#: TYPE NAME SIZE IDENTIFIER

0: *31.5 GB disk7


imac-de-lapeyre-2-1:~ lapeyredominique$ sudo gpt show /dev/disk7

Password:

start size index contents

0 61440000

imac-de-lapeyre-2-1:~ lapeyredominique$
 
Le tableau me fait penser à la phrase de Tacite : « ubi solitudinem faciunt, pacem appellant » (où ils ont fait un désert, ils disent qu'ils ont apporté la paix). Ta clé est on ne peut plus paisible, étant donné que son disque est un désert
361608_original.png
(je ne devrais pas rire, mais c'est plus fort que moi)

Car le retour que tu obtiens :
Bloc de code:
0 61440000
consiste simplement dans une désignation du début et de la fin des blocs (bloc = alignement de 512 octets de 8 bits) du disque => début = bloc 0 > fin = bloc 61440000. Tu peux faire le compte : 61440000 x 512 octets = 31457280000 = 31.45 Go.

À part ce dénombrement numérique > rien. Nada. Aucun contenu d'écritures. Zéro table de partition. Zéro secteur de partition. Pour faire encore la comparaison > voici ce que j'obtiens sur ma clé de 15 Go :
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  30079920      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  30489560    262151     
  30751711        32         Sec GPT table
  30751743         1         Sec GPT header

=> tu remarques que, sur ma clé, le bloc 0 a pour contenu une PMBR (Protective_MBR = table de partition secondaire) > les blocs 1 > 32 ont pour contenu une GPT (GUID_Partition_Table = table de partition principale) > entre 2 secteurs de blocs libres 2 GPT part = partitions GPT (la 1ère étant la partition EFI d'en-tête > la 2è étant la partition principale, dont le système de fichiers JHFS+ monte le volume CLE) > ensuite sur les 32 derniers blocs se trouve le backup (sauvegarde) de la GPT de départ de disque.

Donc il y a bien un secteur d'amorçage (blocs 0 > 32) comportant 2 tables de partitions, dont la principale fait exister les partitions suivantes sur les blocs.

Chez toi : rien de rien. 0 table de partition > en conséquence 0 partitions > 0 volume montable. Tu n'as pas par hasard approché ta clé d'un aimant ? C'est comme si tout le paramétrage logique du disque avait été zappé pfuiiit !

En résumé : je ne peux rien pour toi.

Si tu voulais récupérer des données > il n'y a plus qu'à utiliser un logiciel de récupération (genre «Data Rescue» ou «Stella Mac Recovery»), parce qu'ils sont capables de lire les blocs bruts pour y détecter des séquences d'écriture, en l'absence de système de fichiers (u as une alternative gratuite, qui est l'exécutable photorec utilisable en ligne de commande dans le «Terminal» seulement). Sinon : tu n'as plus qu'à ré-initialiser ta clé > ce qui ré-écrira une table de partition (ou 2 avec la MBR secondaire) sur le secteur d'amorçage.
 
Dernière édition par un modérateur:
  • J’aime
Réactions: Dom44
Le tableau me fait penser à la phrase de Tacite : « ubi solitudinem faciunt, pacem appellant » (où ils ont fait un désert, ils disent qu'ils ont apporté la paix). Ta clé est on ne peut plus paisible, étant donné que son disque est un désert
361608_original.png
(je ne devrais pas rire, mais c'est plus fort que moi)

Car le retour que tu obtiens :
Bloc de code:
0 61440000
consiste simplement dans une désignation du début et de la fin des blocs (bloc = alignement de 512 octets de 8 bits) du disque => début = bloc 0 > fin = bloc 61440000. Tu peux faire le compte : 61440000 x 512 octets = 31457280000 = 31.45 Go.

À part ce dénombrement numérique > rien. Nada. Aucun contenu d'écritures. Zéro table de partition. Zéro secteur de partition. Pour faire encore la comparaison > voici ce que j'obtiens sur ma clé de 15 Go :
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  30079920      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  30489560    262151    
  30751711        32         Sec GPT table
  30751743         1         Sec GPT header

=> tu remarques que, sur ma clé, le bloc 0 a pour contenu une PMBR (Protective_MBR = table de partition secondaire) > les blocs 1 > 32 ont pour contenu une GPT (GUID_Partition_Table = table de partition principale) > entre 2 secteurs de blocs libres 2 GPT part = partitions GPT (la 1ère étant la partition EFI d'en-tête > la 2è étant la partition principale, dont le système de fichiers JHFS+ monte le volume CLE) > ensuite sur les 32 derniers blocs se trouve le backup (sauvegarde) de la GPT de départ de disque.

Donc il y a bien un secteur d'amorçage (blocs 0 > 32) comportant 2 tables de partitions, dont la principale fait exister les partitions suivantes sur les blocs.

Chez toi : rien de rien. 0 table de partition > en conséquence 0 partitions > 0 volume montable. Tu n'as pas par hasard approché ta clé d'un aimant ? C'est comme si tout le paramétrage logique du disque avait été zappé pfuiiit !

En résumé : je ne peux rien pour toi.

Si tu voulais récupérer des données > il n'y a plus qu'à utiliser un logiciel de récupération (genre «Data Rescue» ou «Stella Mac Recovery»), parce qu'ils sont capables de lire les blocs bruts pour y détecter des séquences d'écriture, en l'absence de système de fichiers (u as une alternative gratuite, qui est l'exécutable photorec utilisable en ligne de commande dans le «Terminal» seulement). Sinon : tu n'as plus qu'à ré-initialiser ta clé > ce qui ré-écrira une table de partition (ou 2 avec la MBR secondaire) sur le secteur d'amorçage.
Merci de cette réponse directe, je sais donc où je vais. Je vais essayer les deux logiciels de récupération. À la prochaine, amicalement
 
Quand j'ai dit que je ne pouvais rien pour toi, j'entendais en mode action directe (genre : te passer telle ou telle commande "magique"). Mais je me suis dit entre temps : tiens ! pourquoi ne pas expérimenter de mon côté ?

Je me suis donc livré à une série de manœuvres avec la clé USB qui m'a servi ici de comparatif.

- 1° À l'aide d'un utilitaire de tierce partie (gdisk de Roderick Smith) > j'ai zappé toutes les tables de partitions du disque de cette clé. Une commande diskutil list me retourne donc un :
Bloc de code:
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *15.7 GB    disk5
absolument analogue à ton cas. J'éjecte ma clé > je la réattache : même annonce => "Le disque que vous avez inséré n'est pas lisible par cet ordinateur".

- 2° Je passe la commande sudo gpt show à destination du disque en question et j'obtiens en retour :
Bloc de code:
    start      size  index  contents
        0  30751744
càd. la même issue qu'avec ta clé.

- 3° J'appelle alors l'utilitaire testdisk de Philippe Grenier sur la clé par un :
Bloc de code:
sudo testdisk /dev/disk5
(il s'agit d'un utilitaire spécialisé dans la récupération des tables de partitions - donc un exécutable qui scanne la carte d'amorçage du disque-cible en somme : les blocs 0 à 32).

L'utilitaire n'a pas eu de difficulté, d'après les écritures résiduelles de ces blocs de tête, à reconstruire les fichiers descripteurs, et après quoi ? un peu moins d'une minute d'interactivité dans l'interface du programme > j'ai activé l'option d'écriture des tables de partition reconstruites. Il m'a suffi alors de quitter l'exécutable pour qu'un volume intitulé CLE s'affiche sur le Bureau, contenant les fichiers que j'y avais copiés au préalable en guise de test.

Ainsi donc testdisk convenablement dirigé a reconstruit la table de partition GPT du disque de la clé > permettant par là la redescription des partitions > avec leurs systèmes de fichiers > et par suite la possibilité de remonter le volume de la partition principale > avec affichage des fichiers recelés.

Je présume alors que tu aurais une chance raisonnable de récupérer pareillement la table de partition du disque de ta clé - pour autant que tu ne l'aies pas réinitialisé. Car il n'y a jamais que 33 blocs en tout si ta table de partition était GPT - sinon 1 bloc seulement = le bloc 0 si tu avais une MBR directrice - qui soient scannés pour récupération des fichiers descripteurs. Tout le reste des blocs du disque de la clé a gardé ses écritures intactes en l'état (du moins celui de ma clé) > et il suffit alors que les descripteurs du secteur d'amorçage soient réécrits pour que tout réapparaisse imméditament comme avant.
 
Quand j'ai dit que je ne pouvais rien pour toi, j'entendais en mode action directe (genre : te passer telle ou telle commande "magique"). Mais je me suis dit entre temps : tiens ! pourquoi ne pas expérimenter de mon côté ?

Je me suis donc livré à une série de manœuvres avec la clé USB qui m'a servi ici de comparatif.

- 1° À l'aide d'un utilitaire de tierce partie (gdisk de Roderick Smith) > j'ai zappé toutes les tables de partitions du disque de cette clé. Une commande diskutil list me retourne donc un :
Bloc de code:
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                                                   *15.7 GB    disk5
absolument analogue à ton cas. J'éjecte ma clé > je la réattache : même annonce => "Le disque que vous avez inséré n'est pas lisible par cet ordinateur".

- 2° Je passe la commande sudo gpt show à destination du disque en question et j'obtiens en retour :
Bloc de code:
    start      size  index  contents
        0  30751744
càd. la même issue qu'avec ta clé.

- 3° J'appelle alors l'utilitaire testdisk de Philippe Grenier sur la clé par un :
Bloc de code:
sudo testdisk /dev/disk5
(il s'agit d'un utilitaire spécialisé dans la récupération des tables de partitions - donc un exécutable qui scanne la carte d'amorçage du disque-cible en somme : les blocs 0 à 32).

L'utilitaire n'a pas eu de difficulté, d'après les écritures résiduelles de ces blocs de tête, à reconstruire les fichiers descripteurs, et après quoi ? un peu moins d'une minute d'interactivité dans l'interface du programme > j'ai activé l'option d'écriture des tables de partition reconstruites. Il m'a suffi alors de quitter l'exécutable pour qu'un volume intitulé CLE s'affiche sur le Bureau, contenant les fichiers que j'y avais copiés au préalable en guise de test.

Ainsi donc testdisk convenablement dirigé a reconstruit la table de partition GPT du disque de la clé > permettant par là la redescription des partitions > avec leurs systèmes de fichiers > et par suite la possibilité de remonter le volume de la partition principale > avec affichage des fichiers recelés.

Je présume alors que tu aurais une chance raisonnable de récupérer pareillement la table de partition du disque de ta clé - pour autant que tu ne l'aies pas réinitialisé. Car il n'y a jamais que 33 blocs en tout si ta table de partition était GPT - sinon 1 bloc seulement = le bloc 0 si tu avais une MBR directrice - qui soient scannés pour récupération des fichiers descripteurs. Tout le reste des blocs du disque de la clé a gardé ses écritures intactes en l'état (du moins celui de ma clé) > et il suffit alors que les descripteurs du secteur d'amorçage soient réécrits pour que tout réapparaisse imméditament comme avant.
J'ai encore du m'absenter de mon domicile et je n'avais plus grand espoir de retrouver quelque chose... Mais cette nouvelle réponse m'a apporté du nouveau. Testdisk me donne ainsi cette réponse pour la clé "muette" :

Disk /dev/disk2 - 31 GB / 29 GiB - CHS 61440000 1 1
Function write_part_mac not implemented

Use pdisk (Mac) or parted (Linux) to recreate the missing partition

using values displayed by TestDisk




Partition Start End Size in sectors


P DOS_FAT_32 64 61439999 61439936 [DL 32 GO]

Mais c'est là que ça coince pour moi... Comment activer le "retour" de la clé ?
 
Désolé, mais je n'avais pas vu que le Terminal travaillait... et la recherche est toujours en activité. Par contre, il y a eu un arrêt impromptu avec :

Disk /dev/disk2 - 31 GB / 29 GiB - CHS 61440000 1 1






Unknown 1 61439999 61439999








Enter the starting sector (8-61439999) : s dans les cinq premi res
et, quand le test a été terminé, j'avais en réponse :

Disk /dev/disk2 - 31 GB / 29 GiB - CHS 61440000 1 1

Partition Start End Size in sectors



Mais le disk n'est toujours pas lisible par mon iMac...
A priori, je ne bouge pas dans les prochaines 48 heures !

En toute amitié,
Dom














Keys A: add partition, L: load backup, Enter: to continue
 
Salut Dom

Je viens de re-essayer testdisk avec la même clé dans 2 configurations initiales différentes successives (BROL est le nom du volume qui monte) :

- a) table de partition GPT = 2 partitions => n°1 EFI : EFI > n°2 Apple_HFS : BROL (contenant une poignée d'images .png).

- b) table de partition MBR = 1 partition => n°1 FAT32 : BROL (contenant la même poignée d'images .png).​

J'appelle un utilitaire (gdisk pour la config a et fdisk pour la config b) et je lui fait zapper toutes tables de partition sur l'en-tête du disque. J'obtiens une clé dans le même état que la tienne : après détachement et ré-attachement > elle n'est pas reconnue lisible par l'ordinateur (plus de table de partition > plus de patition > plus de volume).

J'appelle tesdisk > en choisissant chaque fois le type de table de partition (EFI-GPT ou Intel-PC) > et j'enchaîne les panneaux interactifs en laissant bien faire le travail d'analyse jusqu'au bout dans le panneau qui le signale.

Les 2 fois successives > j'ai la capacité de choisir la reconstruction d'une table de partition ad hoc (GPT ou MBR) avec description d'une partition BROL (soit de format HFS, soit de format FAT32) > je veille soigneusement dans le panneau ad hoc encore à déplacer la sélection (en bas de panneau) sur : WRITE (afin d'écrire la table de partition : si GPT > ça se fera sur les 32 premiers blocs ; si MBR > sur le bloc 0).

J'obtiens le message : "vous devez re-démarrer..." (parce que le kernel ne va pas charger en mode "live" la table de partition écrite sur le secteur d'amorçage). Je quitte le logiciel > laisse ma clé attachée > re-démarre le Mac > ré-ouvre ma session > les 2 fois successives un volume BROL monte et son icône s'affiche sur le Bureau > en ouvrant ce répertoire les fichiers .png sont au rendez-vous.

CAVEAT! si tu t'y prends mal et demande d'écrire une table de partition incorrecte > tu risques d'aliéner tes chances de récupérer ton volume.
 
Salut Dom

Je viens de re-essayer testdisk avec la même clé dans 2 configurations initiales différentes successives (BROL est le nom du volume qui monte) :

- a) table de partition GPT = 2 partitions => n°1 EFI : EFI > n°2 Apple_HFS : BROL (contenant une poignée d'images .png).

- b) table de partition MBR = 1 partition => n°1 FAT32 : BROL (contenant la même poignée d'images .png).​

J'appelle un utilitaire (gdisk pour la config a et fdisk pour la config b) et je lui fait zapper toutes tables de partition sur l'en-tête du disque. J'obtiens une clé dans le même état que la tienne : après détachement et ré-attachement > elle n'est pas reconnue lisible par l'ordinateur (plus de table de partition > plus de patition > plus de volume).

J'appelle tesdisk > en choisissant chaque fois le type de table de partition (EFI-GPT ou Intel-PC) > et j'enchaîne les panneaux interactifs en laissant bien faire le travail d'analyse jusqu'au bout dans le panneau qui le signale.

Les 2 fois successives > j'ai la capacité de choisir la reconstruction d'une table de partition ad hoc (GPT ou MBR) avec description d'une partition BROL (soit de format HFS, soit de format FAT32) > je veille soigneusement dans le panneau ad hoc encore à déplacer la sélection (en bas de panneau) sur : WRITE (afin d'écrire la table de partition : si GPT > ça se fera sur les 32 premiers blocs ; si MBR > sur le bloc 0).

J'obtiens le message : "vous devez re-démarrer..." (parce que le kernel ne va pas charger en mode "live" la table de partition écrite sur le secteur d'amorçage). Je quitte le logiciel > laisse ma clé attachée > re-démarre le Mac > ré-ouvre ma session > les 2 fois successives un volume BROL monte et son icône s'affiche sur le Bureau > en ouvrant ce répertoire les fichiers .png sont au rendez-vous.

CAVEAT! si tu t'y prends mal et demande d'écrire une table de partition incorrecte > tu risques d'aliéner tes chances de récupérer ton volume.

J'ai rarement vu, ou peut-etre jamais, une personne qui se se soit autant implique dans la resolution d'un probleme. C'est fort dommage de ne pas avoir la suite de ce fil de discussion, ne serait-ce que pour lire un merci !

Si je suis arrivé sur cette discussion c'est parce que je dois faire le montage photo pour le mariage d'un ami et que mon disque dur ne se monte plus... Je suis en panique totale. Lorsque je lance testdisk depuis un terminal sur mon mac (Mojave) il n'est pas installe. Et lorsque j'essaye depuis un Ubuntu 19.04 sur VirtualBox, je n'arrive pas a mes fins. Au moment de cliquer "write" j'ai l'erreur function write_part_mac not implemented. Use pdisk (mac) or parted(linux) to recreate the missing partition... Du coup je bloque, j'ai un peu peur de tout faire foirer. C'est possible de me filer un coup de main? pour accelerer le debug je veux bien utiliser le partage ecran, skype, slack, discord... ce que voudra la personne qui voudra bien m'aider :)