Moving from HDD to SSD - facing some issues (GPT protective partition)

Question

I am trying to move my pc from old HDD into new SSD
I put the new SSD in , installed windows 10
Then I connected the old HDD into the new windows so I can move the data from the old drive.
using USB 3 cable and external enclosure,
but Disk Management shows (GPT protective partition)

What is this GPT protective partition?
I have a backup but is there a way around this?

Thank you!

Disk Management Drive

Update
I tried following this article.
but I don't see the Convert to MBR Option enter image description here

UPDATE 2
Yes, Its a 3.5 drive
per request the drive details:

enter image description here

Update 4
multiple comments blame the enclosure,
So I purchased new adapter from amazon, it should arrive tomorrow, ill post the results.

If you recommend another adapter please let me know!

UPDATE 5

Thank you all very much! replaced the enclosure and able to access all the files!! i had 99% in my backups but still great to know not missing anything! Many thank you! I really appreciate your help!

• oldfred: Windows only installs in UEFI mode to gpt partitioned drives. And only in BIOS mode to MBR(msdos) partitioned drives. When gpt was relatively new many old partitioning tools did not work with gpt, so gpt has a protective MBR or first sector of drive and it just has one MBR type entry saying drive is gpt. Then old tools at least would see drive is partitioned and not erase it. But you should then see gpt partitions.
• Ramhound: I am suspicious of the external enclosure. Older USB enclosures use some pretty odd tricks. This a 3.5" desktop or 2.5" laptop drive?
• grawity: Do you know if this is a "4K native" disk (with 4096-byte sectors), as opposed to a regular 512b disk?
• JW0914: Bypass the external enclosure altogether by removing the drive from the enclosure and installing it directly in the PC. I'm curious if it would register correctly in WinPE/WinRE. Please add to your question the output of the following from diskpart (WinKey + R > Open: diskpart): sel dis 5 > lis par
• harrymc: What model is the HDD and what is its real size? Is it really MBR?

Answer 1

Obviously it's because the enclosure reports the Logical Block Size to be 4KiB while the actual LBS of the disk is 512 bytes. (For the record it doesn't matter if it is 512e or 512n regarding the issue; in either case the LBS is 512 bytes.)

The fact that the partition entry (of 0xffffffff blocks, the maximum one can represents) in the "Protective MBR" is being recognized as ~16TiB indicates the case. (For the record, Windows uses 0xffffffff as the size of the "protective partition" regardless of the actual size of the drive.)

While it might have "properly grouped" the 512-byte blocks to "another layer" of logical blocks of 4096 bytes (which explains why the total size is correct in your second screenshot), it doesn't mean the content that was written to the disk with LBS of 512 bytes "in mind" can be read properly with the given situation.

For example, Windows will try to read the GPT from the actual ninth logical block, while it is on the actual second logical block. The fact that you are seeing the "protective partition" indicates the case (GPT not found).

The following simulates the situation:

[tom@archlinux ~]$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 238.49 GiB, 256060514304 bytes, 500118192 sectors
Disk model: id State Disk 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 90C9AA0F-22B4-426F-B347-14412F4E447E
Device Start End Sectors Size Type
/dev/sdc1 2048 1085439 1083392 529M Windows recovery environment
/dev/sdc2 1085440 1288191 202752 99M EFI System
/dev/sdc3 1288192 1320959 32768 16M Microsoft reserved
/dev/sdc4 1320960 500117503 498796544 237.9G Microsoft basic data
[tom@archlinux ~]$ sudo fdisk -b 4096 -l /dev/sdc
Disk /dev/sdc: 238.49 GiB, 256060514304 bytes, 62514774 sectors
Disk model: id State Disk 
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdc1 1 4294967295 4294967295 16T ee GPT
[tom@archlinux ~]$ 

TL;DR, just don't do anything to the disk with the enclosure, as it's only gonna mess up the data. Get another one that doesn't do this sort of "4KiB emulation".

P.S. You can check an enclosure with PowerShell cmdlets. You will see the logical sector size being 4096 bytes with one that does the aforementioned "emulation": enter image description here It does not have anything to do with the capacity of your drive, USB version the enclosure is of, but its response to a SCSI READ CAPACITY command (i.e. how its firmware is written).

• JavaSheriff: Thank you very much! replaced the enclosure and able to access all the files!! many thank you! I really appreciate your help

Answer 2

The problem is most likely that the external enclosure being used is unsuitable for the disk.

Your disk is the Toshiba MD04ACA400, advertised as 4 TB (decimal notation) and formatted under Windows as 3.64 TB (binary notation). It is likely formatted as GPT, since the disk is too large for MBR (unless all disk space beyond 2.2 TB is to be abandoned).

The enclosure is probably of type USB 2.0 that can only correctly contain disks whose size is expressible in 32-bits, so cannot be used for disks larger than 2.2 TB.

I suggest either getting a newer enclosure that can handle a disk of this capacity, or connecting the disk internally.

• Tom Yan: It will work once the drive is cleaned and re-partitioned, but will "stop working" again once it is out of the enclosure and connected to SATA directly (before the aforementioned procedures are done, again). See my (updated) answer for the reason. It has nothing to do with USB 2.0 (neither does that pose any "32-bit limitation").
• harrymc: @TomYan: Do you know what you are talking about? The question is about making a disk work as before. The disk is OK.
• Tom Yan: Yeah the disk is okay, so is the enclosure (sort of). It's just the data that's already on the drive won't be okay if manipulations are done via the enclosure.
• harrymc: @TomYan: That's exactly what I'm saying not to do, so I don't understand your comment at all (and a downvote?).
• Tom Yan: Well, as it's not about capacity / USB 2.0. (Well yeah, "unsuitable" is right.)