Minha situação parece muito semelhante a como consertar o disco rígido GUID corrompido no MBR, mas com diferenças suficientes que não consegui montar uma solução confiável.
Eu tenho uma unidade Toshiba de 3 TB em um gabinete USB que está sendo usada em um Mac com OS X El Capitain 10.11.3.
A unidade foi configurada com uma única partição. A unidade não era inicializável e não tinha um sistema instalado, portanto, suponho que ela também não teria uma partição de recuperação. Não posso ter certeza de que nunca houve um sistema instalado, mas acho que não. Não foi usado com o Bootcamp ou em qualquer computador que não seja Mac.
A unidade funcionou normalmente por um longo período de tempo, mas falhou em ser reconhecida recentemente. Ao investigar com o Disk Utility, ele mostra um tipo de partição FDisk_partition_scheme . Tenho certeza de que era originalmente o padrão típico do Mapa de Partição GUID formatado como OS X Extended (Diário) .
Não consigo pensar em nenhum uso ou evento específico que possa ter causado a alteração.
Aqui estão as informações que eu coletei da unidade.
lista diskutil / dev / disk6
/dev/disk6 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *3.0 TB disk6
1: 0xEE 375.1 GB disk6s1
diskutil info / dev / disk6
Device Identifier: disk6
Device Node: /dev/disk6
Whole: Yes
Part of Whole: disk6
Device / Media Name: DT01ABA300
Volume Name: Not applicable (no file system)
Mounted: Not applicable (no file system)
File System: None
Content (IOContent): FDisk_partition_scheme
OS Can Be Installed: No
Media Type: Generic
Protocol: USB
SMART Status: Not Supported
Total Size: 3.0 TB (3000592982016 Bytes) (exactly 5860533168 512-Byte-Units)
Volume Free Space: Not applicable (no file system)
Device Block Size: 512 Bytes
Read-Only Media: No
Read-Only Volume: Not applicable (no file system)
Device Location: External
Removable Media: No
Virtual: No
OS 9 Drivers: No
Low Level Format: Not supported
fdisk / dev / disk6
Disk: /dev/disk6 geometry: 97451/255/63 [1565565872 sectors]
Signature: 0xAA55
Starting Ending
#: id cyl hd sec - cyl hd sec [ start - size]
------------------------------------------------------------------------
1: EE 1023 254 63 - 1023 254 63 [ 1 - 732566645] <Unknown ID>
2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused
gpt recuperar / dev / disk6
gpt recover: /dev/disk6: no primary or secondary GPT headers, can't recover
gpt -r -vv mostra / dev / disk6
gpt show: /dev/disk6: mediasize=3000592982016; sectorsize=512; blocks=5860533168
gpt show: /dev/disk6: PMBR at sector 0
start size index contents
0 1 PMBR
1 5860533167
gdisk / dev / disk6
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: not present
Creating new GPT entries.
Aqui está uma captura de tela da primeira parte da unidade no wxHexEditor. A EFI PART começa em 4096.
Comecei a procurar a string HFSJ iniciando com um deslocamento de 409642, conforme sugerido em outras respostas, mas não a encontrei por perto. Então, procurei a partir do início da unidade e encontrei a primeira ocorrência no deslocamento 314598400.
No entanto, se eu continuo procurando por ocorrências do HFSJ, encontro muitas delas com a mesma aparência e com muito espaço zero à sua volta, como a primeira. Aqueles começam em 360424448 e estão espaçados 32768. Por exemplo, nas compensações 360424448 360457216 360489984 360522752 360555520
Usei a pesquisa Localizar tudo no wxHexEditor e parei depois de alguns minutos. Encontrara alguns milhares naquele momento. Não sei bem o que fazer com essas coisas, se é que alguma coisa.
Também pude encontrar uma seção denominada Partição do sistema EFI no deslocamento 3000592961536. Isso também mostra o nome da unidade, "Rosie".
Aqui estão as capturas de tela da primeira partição HFSJ e da partição do sistema EFI. Adicionada uma captura de tela do deslocamento 8192 com base nos comentários.
Obrigado por qualquer ajuda.
0+0 records in 0+0 records out 0 bytes transferred in 0.000013 secs (0 bytes/sec)