10.13 High Sierra How to fix my corrupted APFS container?

[Rainyday]

[Désolé les gars, je ne connais pas le français et j'ai vraiment besoin de l'aide de votre communauté. S'il vous plaît approuver mon fil écrit en anglais et m'aider à sauver un SSD drive contenant mes souvenirs de famille.]


`MBP late 13` running `10.13.2` on a `Samsung Evo 850 250GB`

Everything was fine for months but few days ago something horrible occurred. I'm so shocked and urgently need your help.

Finder wasn't responding and I had to restart it by force. But it didn't boot again and just showed a black screen. Tried several times without success which finally I had to install another High Sierra on my 2nd drive (a healthy HDD)

• Here's few shots which convince me that the `APFS container` is damaged (SSD=disk0):

Disk0s2 - part1

Disk0s2 - part2

Container

Weird thing called Synthesized

Diskutil list

Diskutil apfs list

Diskutil repairDisk/repairVloume



• Here's few notes which probably help you know where the error lies:


Note1 : Used a third party app and it found 4 partitions including VM , Recovery , Macintosh SSD , Preboot. Tried to recovery data from Macintosh SSD partition and fortunately it was intact and apparently all files were healthy and existed. That's why I think it's just a corruption of the `APFS container`.



-------------------------

Please help me repair the disk and take back the OS. The drive looks like healthy and Repairable.

 

[bompi]

[Your French seems good enough to me...]

I've seen your post on MacRumors and I agree with the first (and sole) reply : your second drive partitioning is quite unusual, with several APFS containers.
Have you also tried Apple forums ?

Anyway, from the French part of your post , I understand you don't have any backup available, either Time Machine or a clone.
Hence, first things first : copy all the data you're able to get with iBoySoft software on a drive.

Once the backup done, I'm afraid you'll have to rebuild (erase + format) your drive, reinstall the OS and put back all your saved data.
So far I haven't got any hint on repairing a failed APFS container when the official command (diskutil repairVolume <disk slice>) is useless.

 

[Locke]

[Désolé les gars, je ne connais pas le français et j'ai vraiment besoin de l'aide de votre communauté. S'il vous plaît approuver mon fil écrit en anglais et m'aider à sauver un SSD drive contenant mes souvenirs de famille.]

Ah bon, pourtant c'est très clair au début.

 

[flotow]

oh yeah @macomaniac in english



dommage, le copier coller ne fonctionnera pas cette fois ci


Clover Configurator > Hackintosh ?!

 

[bompi]

oh yeah @macomaniac in english



dommage, le copier coller ne fonctionnera pas cette fois ci


Clover Configurator > Hackintosh ?!

Un hackintosh sur un MBP, bigre...

 

[Rainyday]

[Your French seems good enough to me...]

I've seen your post on MacRumors and I agree with the first (and sole) reply : your second drive partitioning is quite unusual, with several APFS containers.
Have you also tried Apple forums ?

Anyway, from the French part of your post , I understand you don't have any backup available, either Time Machine or a clone.
Hence, first things first : copy all the data you're able to get with iBoySoft software on a drive.

Once the backup done, I'm afraid you'll have to rebuild (erase + format) your drive, reinstall the OS and put back all your saved data.
So far I haven't got any hint on repairing a failed APFS container when the official command (diskutil repairVolume <disk slice>) is useless.

[I should have said it before that it was a google try not mine!]

Let me at first thank you for you concern.

I'm going to try Apple discussion as soon as possible. I'd be glad if you could check out that page again.

Thank you for nice understanding! So glad to see clever guys participating in the thread!

It would be a long post so let me please take it apart to get more of your next valuable answer.

1st: I've already tried to pull my data from the disk. Almost 90% of my recovered data are healthy though some .TREC files (Camtasia recording format) are not playable anymore. Checked by Hex Fiend and found out that the end of those files is cut suddenly (fault of recovery app?)
I guess if I could repair (rebuild) the container then ALL data including corrupted .trec files would come healthy again. Let me know if you agree with me.

2nd: Unfortunately, I need to gain the access to the OS even for 2min to do sth critical. Then obviously I'd go for a clean installation, for sure. Any chance?

3rd: First idea which may sound weird. Of course I need your help to refine it

- Possible to somehow get a clone/copy/backup of the OS partition (macSSD in the shot) then try to install a fresh High sierra and merge/overwrite the vanilla partition with that backed up partition in order to regain exactly the old OS consisting all setting and data? Does it work like this or it's just my dream?

4th: Second idea and the last one probably

- Take an image/clone of the SSD and waiting for next major release of DiskWorrior in order to rebuild and fix the corrupted container. I don't know whether it's technically possible to repair an IMAGE/CLONE or not (by DW or other upcoming tools) So due to be a newbie I again need your help to refine this one too![/QUOTE]

 

[Membre supprimé 1060554]

Hi Rainyday !

You got me to writing the technical parts in French here. You may answer using English without any trouble.

Voici le partitionnement du SSD Samsung EVO :

/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         250.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk2         249.8 GB   disk0s2

• pas d'anomalie ici : la partition disk0s2 a un type Apple_APFS. Elle contient un magasin de stockage physique appelé Physical Store. Ce Physical Store sert de base d'exportation d'un espace-disque virtuel appelé Conteneur et dont l'index de disque virtuel est disk2.

Voici la description du Conteneur disk2 :

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +ERROR      disk2
                                 Physical Store disk0s2

• on voit bien que le magasin de stockage physique servant de base d'exportation est le Physical Store disk0s2. Ce qui frappe d'abord est que le Conteneur disk2 se trouve exporté avec une erreur de taille de l'espace-disque virtuel. Il devrait y avoir à la place -->

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                       249.8 GB   disk2
                                 Physical Store disk0s2

• ce qui frappe ensuite est que le Conteneur disk2 ne porte pas de Volume APFS > alors qu'il devrait y en avoir 4 d'après ton logiciel de récupération de données. Attention ! un Volume APFS est désigné à la façon d'une partition de disque (disk2s1 > disk2s2 > disk2s3 > disk3s4) > mais il ne s'agit pas de réelles partitions. Ce qui donnerait :

/dev/disk2 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                       249.8 GB   disk2
                                 Physical Store disk0s2
   1:                APFS Volume MacSSD                  xxx.x GB   disk2s1
   2:                APFS Volume Preboot                 22.3 MB    disk2s2
   3:                APFS Volume Recovery                519.0 MB   disk2s3
   4:                APFS Volume VM                      xx.x GB    disk2s4

----------

Passe la commande :

diskutil verifyVolume disk2

• la commande vérifie le système de fichiers apfs générateur du Conteneur disk2 et de ses volumes

Poste l'affichage qui est retourné par un copier-coller dans une fenêtre de code ainsi -->

• dans la page de ce fil de MacGé > presse le bouton
  
  ici :
  
  
  menu  : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)

 

[flotow]

You got me to writing the technical parts in French here. You may answer using English without any trouble.

zis iz a little bit bending the rulzes of ze sread dir @macomaniac!

 

[bompi]

1st point : indeed. It looks like some links between parts of files are lost. Repairing would probably help for some files and leave others in an uncomplete state (either erased or place in some trash directory, as UNIX used to do).
But at this point repair doesn't succeed. Maybe try and repair several times in a row may improve the results (as it once did with HFS+) but I wouldn't bet on it.

2d point : at this point, no way (still : I may be wrong but it's beyond my current knowledge).

3rd point is highly unlikely to succeed : APFS inner architecture is too sophisticated. It integrates logical volumes and snapshots which prevent any direct access to data.

4th point is worth trying : if you can spare 250 GB on a drive, that's an option. However you would have to clone the disk, at block level, for instance with the dd text command.
dd won't heed the actual formats of the partitions : copying the whole APFS container should not be an issue, as long as the hardware is still sane (sometime, logical issues are the top of the iceberg...)
I'm still puzzled by the lack of information and tools offered by Apple on APFS...

 

[Rainyday]

Hi Rainyday !

You got me to writing the technical parts in French here. You may answer using English without any trouble.

Voici le partitionnement du SSD Samsung EVO :

/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         250.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk2         249.8 GB   disk0s2

• pas d'anomalie ici : la partition disk0s2 a un type Apple_APFS. Elle contient un magasin de stockage physique appelé Physical Store. Ce Physical Store sert de base d'exportation d'un espace-disque virtuel appelé Conteneur et dont l'index de disque virtuel est disk2.

...

Hi macomaniac!.

So glad to see you here, my man! Apologize you all for the long encountered delay. I had no choice..

Let's begin with the mentioned command.

MacBook-Pro:~ rainyhighsierra$ diskutil verifyVolume disk2
Started file system verification on disk2
Verifying storage system
Performing fsck_apfs -n -x /dev/disk0s2
Checking volume
Checking the container superblock
error: object (oid 0x1): o_cksum (0x7f23daf6f220955d) is invalid for object
warning: checkpoint 247 fsck_obj_phys failed
error: object (oid 0x107): o_cksum (0xe096dd51deca9041) is invalid for object
warning: checkpoint 262 fsck_obj_phys failed
error: object (oid 0x10b): o_cksum (0x661d289dd9202cbd) is invalid for object
warning: checkpoint 266 fsck_obj_phys failed
Checking the EFI jumpstart record
error: (oid 0x2aac6) nrl: invalid o_cksum (0x8eaa1aec711175bb)
error: verification/reading of the nx_reaper object failed
The volume /dev/disk0s2 could not be verified completely
Storage system check exit code is 0
Finished file system verification on disk2

Let me know please what above lines are talking about.

• Need to say again, all data on the disk is intact and healthy. Just, as you said elsewhere above, it lies on the lost Volumes of the disk2. I think I had a similar case few years ago on a Windows machine (NTFS disk) and a free tool called TestDisk managed to find and re-map the lost partitions successfully. It's available on OS X but never been claimed to be able to repair APFS. Does it worth to give it a try or it could be harmful? I wish there was a specific tool to repair APFS too.

• It doesn't take long for you to see another person whining about an exactly same problem on this forum. Imagine I forget everything and easily reformat the disk. There's no any guarantee to not lose the container again in near future. So there should be a way to fix it (esp. when the disk and its data are both healthy). As el moderador bompi said before, it's so bizarre to just introduce a completely brand-new THING without any kind of documentation and specific related tools.

 

[Rainyday]

1st point : indeed. It looks like some links between parts of files are lost. Repairing would probably help for some files and leave others in an uncomplete state (either erased or place in some trash directory, as UNIX used to do).
But at this point repair doesn't succeed. Maybe try and repair several times in a row may improve the results (as it once did with HFS+) but I wouldn't bet on it.

2d point : at this point, no way (still : I may be wrong but it's beyond my current knowledge).

3rd point is highly unlikely to succeed : APFS inner architecture is too sophisticated. It integrates logical volumes and snapshots which prevent any direct access to data.

4th point is worth trying : if you can spare 250 GB on a drive, that's an option. However you would have to clone the disk, at block level, for instance with the dd text command.
dd won't heed the actual formats of the partitions : copying the whole APFS container should not be an issue, as long as the hardware is still sane (sometime, logical issues are the top of the iceberg...)
I'm still puzzled by the lack of information and tools offered by Apple on APFS...

Thank you for all your help.

I've never used dd. Any specific procedure I should follow in this case? (e.g. an additional argument or command or sth else). If possible please give me a preferred article link.

Do I need an empty drive for cloning via dd? Do I need an HFS+ drive necessarily?

At the moment, all my two external HDDs are formatted in Exfat and both are not empty.
Is it necessary for the destination to be empty and in a specific format?

 

[Membre supprimé 1060554]

Voici ce que tu devrais obtenir pour une vérification valide :

Started file system verification on disk02
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2

Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map

Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots

Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots

Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots

Checking the APFS volume superblock
Checking the object map
Checking the fsroot tree
Checking the snapshot metadata tree
Checking the extent ref tree
Checking the snapshots

Verifying allocated space
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Finished file system verification on disk0s2

• c'est moi qui ai opéré les sauts de lignes. Il y a 4 modules vérifiés qui correspondent aux 4 volumes APFS du Conteneur. Mais avant cette vérification "modulaire" > il y a la vérification d'un "tronc commun" -->

Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object map

• c'est sur ce tronc commun que plante la vérification chez toi -->

Checking volume
Checking the container superblock
error: object (oid 0x1): o_cksum (0x7f23daf6f220955d) is invalid for object
warning: checkpoint 247 fsck_obj_phys failed
error: object (oid 0x107): o_cksum (0xe096dd51deca9041) is invalid for object
warning: checkpoint 262 fsck_obj_phys failed
error: object (oid 0x10b): o_cksum (0x661d289dd9202cbd) is invalid for object
warning: checkpoint 266 fsck_obj_phys failed
Checking the EFI jumpstart record
error: (oid 0x2aac6) nrl: invalid o_cksum (0x8eaa1aec711175bb)
error: verification/reading of the nx_reaper object failed

• le « container superblock » est invalide > l'« EFI jumpstart record » est invalide => et à partir de là le reste de l'examen est échappé

Je me représente la partition primaire disk0s2 ainsi : il y a sur les blocs de départ de la partition les « en-têtes » (headers) du système de fichiers apfs > le reste étant occupé par le magasin de stockage Physical Store. Le système de fichiers (dispositif générateur) étant corrompu > il ne se produit qu'une "pseudo-exportation" de l'espace-disque du Conteneur à partir du Physical Store. Aucun volume n'est régénéré. En résumé : il est clair dans ton cas que c'est le "tronc commun" (root) du système de fichiers apfs qui est corrompu.

Je ne dispose pas d'outils (à part l'imagination) pour scruter les rouages de l'apfs > générateur de l'espace-virtuel du Conteneur. Ni non plus d'outil sophistiqué pour intervenir sur tel ou tel rouage en particulier.

Je veux bien te proposer 2 manipulations "gonflées" > mais je ne vois pas en quoi elles répareraient l'apfs > à part un effet "kick in the ass" (si je puis dire). De mémoire > combien avais-tu d'espace libre (environ) dans le Conteneur apfs avant le plantage ?

 

[Rainyday]

Voici ce que tu devrais obtenir pour une vérification valide :

Started file system verification on disk02
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2

Checking volume
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the object mape
Checking the container superblock
[LIST]
[*]c'est sur ce tronc commun que plante la vérification chez toi -->
[/LIST]
[code]Checking volume
Checking the container superblock
error: object (oid 0x1): o_cksum (0x7f23daf6f220955d) is invalid for object
warning: checkpoint 247 fsck_obj_phys failed
error: object (oid 0x107): o_cksum (0xe096dd51deca9041) is invalid for object
warning: checkpoint 262 fsck_obj_phys failed
error: object (oid 0x10b): o_cksum (0x661d289dd9202cbd) is invalid for object
warning: checkpoint 266 fsck_obj_phys failed
Checking the EFI jumpstart record
error: (oid 0x2aac6) nrl: invalid o_cksum (0x8eaa1aec711175bb)
error: verification/reading of the nx_reaper object failed

• le « container superblock » est invalide > l'« EFI jumpstart record » est invalide => et à partir de là le reste de l'examen est échappé

Je me représente la partition primaire disk0s2 ainsi : il y a sur les blocs de départ de la partition les « en-têtes » (headers) du système de fichiers apfs > le reste étant occupé par le magasin de stockage Physical Store. Le système de fichiers (dispositif générateur) étant corrompu > il ne se produit qu'une "pseudo-exportation" de l'espace-disque du Conteneur à partir du Physical Store. Aucun volume n'est régénéré. En résumé : il est clair dans ton cas que c'est le "tronc commun" (root) du système de fichiers apfs qui est corrompu.

Je ne dispose pas d'outils (à part l'imagination) pour scruter les rouages de l'apfs > générateur de l'espace-virtuel du Conteneur. Ni non plus d'outil sophistiqué pour intervenir sur tel ou tel rouage en particulier.

Je veux bien te proposer 2 manipulations "gonflées" > mais je ne vois pas en quoi elles répareraient l'apfs > à part un effet "kick in the ass" (si je puis dire). De mémoire > combien avais-tu d'espace libre (environ) dans le Conteneur apfs avant le plantage ?

Thank you for all great valuable information. I'd appreciate what you've done for me so far.

Your great posts need to be read 3 times at least to get you mean nicely, lots of technical useful words and sometimes not so good translation from google make it a little bit time-consuming process to catch you perfectly right.

I had about 5GB or even less! I know the SSD needs at least %10 of the whole capacity to work properly. I would always try to free space at least ~15-20GB in general but that day I had lots of recording (at 18MB/s bitrate.. yeah 'Byte'..) and to be honest didn't have much time to devote to transfer them to the external HDD. I personally think low free space was one of the main reason of the crashing..

Sorry, macomaniac. In last para, you said 2 manipulation but I didn't catch your mean by 'two'. Could you please say both of them again?

 

[Membre supprimé 1060554]

5 Go (= GB) : ça ne faisait pas beaucoup d'espace libre, en effet.

• le plan A consiste à tenter d'ajouter un volume au Conteneur apfs. Il faut savoir qu'un volume apfs n'a pas de taille fixe à sa création > il a seulement la taille des données qu'il contient au fur et à mesure. Exactement comme une image-disque .sparseimage : vide au départ et augmentant de taille avec les données inscrites dans le volume. Donc créer un nouveau volume ne demande pas un grand espace libre (quelques Ko = KB)

• ce plan a un côté absurde (weird) > puisque le Conteneur apfs actuel n'est pas exporté en tant qu'espace-disque virtuel valide. Disons que le but est de vérifier comme réagit le système de fichiers apfs > à ce type d'instruction.

Passe la commande :

diskutil ap addVolume disk2 apfs SAM

• la commande tente d'ajouter un volume apfs nommé SAM > sur l'espace-disque du Conteneur apfs disk2

Poste l'affichage retourné par la commande --> c'est pour voir s'il y aurait quelque chose d'instructif à lire.

Note : le plan B ensuite.

 

[Rainyday]

Nice trick!

RainyHighSierras-MacBook-Pro:~ rainyhighsierra$ diskutil ap addVolume disk2 apfs SAM
Exporting new APFS Volume "SAM" from APFS Container Reference disk2
Started APFS operation on disk2
Preparing to add APFS Volume to APFS Container disk2
Error: -69620: Unable to get capacity info for an APFS Container or APFS Volume
RainyHighSierras-MacBook-Pro:~ rainyhighsierra$

 

[Membre supprimé 1060554]

Comme on pouvait s'y attendre > la commande se fait rejeter sèchement :

Unable to get capacity info for an APFS Container or APFS Volume

• impossible d'obtenir une information de "capacité" (capacité d'espace-disque) en ce qui concerne un Conteneur apfs ou un Volume apfs (l'espace-disque du Conteneur disk2 est invalide)

Par extrapolation > aucune commande de manipulation adressée au Conteneur disk2 n'a de chance d'aboutir (impasse).

----------

Pour préparer le plan B > passe la commande :

sudo gpt show /dev/disk0

• la commande appelle (en droits root) l'utilitaire gpt (guid_partition_table_utility) > à afficher la distribution des blocs (logical blocks or clusters) du SSD

• elle peut être bloquée - même en simple lecture comme ici - si le SIP (System Integrity Protection) interfère. Mais il ne doit pas jouer de rôle si tu opères depuis un autre disque

Poste le tableau affiché.

Note : tu connais la commande sudo ? --> à la demande de password qui s'affiche > tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide.

 

[Rainyday]

macomaniac? How did you think of me?! I've executed sudo more than 10^[its char's number] = (1 00 00 times!)

lol

RainyHighSierras-MacBook-Pro:~ rainyhighsierra$ sudo gpt show /dev/disk0
Password:
      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  487987488      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
  488397128          7      
  488397135         32         Sec GPT table
  488397167          1         Sec GPT header
RainyHighSierras-MacBook-Pro:~ rainyhighsierra$

Sounds good? I have no idea

 

[Rainyday]

Hello

I think it is possible that the Sata Cable could be out.
If your MBP is a model MacBookPro9,2 (mid-2012) you can try to put SSD in a external box USB and plug it on the Mac.
Then you test if your SSD is reconize correctly.

If it's ok you have to change the Sata Cable.

Bye.

A tool reported something wrong with the power (I didn't remember error/warning text exactly but I'll check it out again ASAP) when I was checking SMART and surface check. It somehow sounds similar to what you are talking about. I'll swipe 2 storage drives (SSD & HDD) and let you know whats going on there. It's a shot in the dark! I'll give it a try. Thank you for participating mate.

 

[Membre supprimé 1060554]

La distribution des blocs est formellement sans bavures. Il est même possible de dire que la taille du bloc utilisée est 512 octets.

Voici la partition de l'apfs -->

     409640  487987488      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC

• si tu veux > je te propose la manœuvre suivante : supprimer dans la table GPT que tu vois ici -->

          1          1         Pri GPT header
          2         32         Pri GPT table

• le descripteur de cette partition n°2 (ce qui ne touche aucun bloc de la partition concernée mais seulement sa description dans la GPT) > recréer un descripteur identique dans la GPT (récupérant au bloc près la localisation précédente de la partition) --> ce qui va "ré-adosser" (si je puis dire) les en-têtes du système de fichiers apfs inscrits sur les blocs de départ de la partition à une "limite initiale". Ce qui "régénère" (réactive) la capacité d'un système de fichiers orphelin de partition --> à définir l'espace de blocs de la partition.

C'est une proposition que je te fais (qui va peut-être te paraître effrayante) --> il n'y a jamais de reformatage impliqué > simplement suppression / recréation d'un descripteur de partition. Là encore l'ambition de la manœuvre est très ténue : miser sur l'effet de "choc" sur le système de fichiers apfs > à la recréation d'une partition dont il occupe l'espace initial. C'est toi qui vois si tu tentes cette manipulation.

 

[Rainyday]

La distribution des blocs est formellement sans bavures. Il est même possible de dire que la taille du bloc utilisée est 512 octets.

Voici la partition de l'apfs -->

     409640  487987488      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC

• si tu veux > je te propose la manœuvre suivante : supprimer dans la table GPT que tu vois ici -->

          1          1         Pri GPT header
          2         32         Pri GPT table

• le descripteur de cette partition n°2 (ce qui ne touche aucun bloc de la partition concernée mais seulement sa description dans la GPT) > recréer un descripteur identique dans la GPT (récupérant au bloc près la localisation précédente de la partition) --> ce qui va "ré-adosser" (si je puis dire) les en-têtes du système de fichiers apfs inscrits sur les blocs de départ de la partition à une "limite initiale". Ce qui "régénère" (réactive) la capacité d'un système de fichiers orphelin de partition --> à définir l'espace de blocs de la partition.

C'est une proposition que je te fais (qui va peut-être te paraître effrayante) --> il n'y a jamais de reformatage impliqué > simplement suppression / recréation d'un descripteur de partition. Là encore l'ambition de la manœuvre est très ténue : miser sur l'effet de "choc" sur le système de fichiers apfs > à la recréation d'une partition dont il occupe l'espace initial. C'est toi qui vois si tu tentes cette manipulation.

I'd be ready for everything after a dd block-level clone. I asked bompi few question regarding this command but didn't get any answer.

You will find me ready for every kind of risky operations. But please let me take a clone first (Albeit, I've already pull all data from path /macSSD/Users/rainyday [~240GB] using DiskDrill) but still I think a bit-by-bit clone needed.


I'll start cloning if i know :

Do I need an empty drive for cloning via dd? Do I need an HFS+ drive necessarily? Would cloning process necessarily format the destination drive?

At the moment, all my two external HDDs are formatted in Exfat and both are not empty.
Is it necessary for the destination to be empty and in a specific file system?