How to 'fix' disk with 512-byte sectors, formatted using an enclosure that translated to 4k sectors

Question

I have a 1TB hard disk with 512-byte sectors that I have been using through a USB disk enclosure for a good many years. However, the enclosure has now died.

When I transferred it to a new enclosure I found that Windows doesn't read it - it just shows up as a 'Local Disk'.

From various research, I have found that the cause is that the original USB enclosure was translating the 512-byte sectors on the disk and presenting them to the outside world as 4k sectors, instead. The new enclosure is not doing this, which is why the disk cannot be read.

I have found a question which sounds like a similar problem (How to correct 512-byte sector MBR on a 4096-byte sector disk?), but (a) from my reading, this sounds like the opposite of my situation; and (b) it doesn't describe the actual steps needed to fix the problem (just a general approach).

---

The theory

Aside from attempting to find another enclosure that does the same kind of translation (which feels like just kicking the can down the road, and an unnecessary expense) the solution, as far as I can glean, is to fix the values in the MBR so that they reflect the real 512-byte disk geometry rather than the previously perceived 4k geometry.

As the partition table sizes are all defined in terms of numbers of sectors, I will need to convert the existing values, which specify the size in 4k sectors (i.e. ByteOffset = N x 4096) so that they instead contain the equivalent value of N for 512-byte sectors (i.e. ByteOffset = N x 512). In other words, I need to multiply each of these values by 8.

Q1: Am I correct - is that all I need to do, or is there more complexity to it than that?

---

The practice

Assuming the above solution is correct, what I am really asking for is whether there is a tool or a set of clear instructions that anyone can provide so that I am able to make these changes to the disk. The less-risky, the better! (For example, tools for direct editing the MBR fields by entering decimal numbers would be preferable to having to deal with hex-values directly on disk.)

Q2: What tool(s) should I use for this (based on the above criteria)?

Q3: What fields/offsets do I need to edit? (The disk has a single partition which fills the disk.)

Note that I have access to the following systems: Windows XP, Windows 10, Ubuntu 15.4. My preference would be for a Windows solution, but a Linux solution would be fine if that is necessary - I am comfortable using the command-line.

Also, I have done byte-level manual disk editing tasks in the past, so this is a possibility if there really is no better way to resolve this.

---

Update

The external drive is a Dynamode 3.5" USB 2.0 enclosure, like this one.

As requested, here is the output from the Linux fdisk command.

root@buttons:~# fdisk -l /dev/sdb

Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000210df

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdb1  *     2048 1953523711 1953521664 931.5G  7 HPFS/NTFS/exFAT

root@buttons:~# fdisk -l /dev/sdb1

Disk /dev/sdb1: 931.5 GiB, 1000203091968 bytes, 1953521664 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2052474d

Device      Boot      Start        End    Sectors   Size Id Type
/dev/sdb1p1 ?       6579571 1924427647 1917848077 914.5G 70 DiskSecure Multi-Boot
/dev/sdb1p2 ?    1953251627 3771827541 1818575915 867.2G 43 unknown
/dev/sdb1p3 ?     225735265  225735274         10     5K 72 unknown
/dev/sdb1p4      2642411520 2642463409      51890  25.3M  0 Empty

Partition table entries are not in disk order.

Answer 1

This is not a direct answer to my question, as it doesn't apply a proper fix to the disk (which is what I am most interested in).

However, from a practical stand-point it solves the problem, in a rather slow and roundabout way.

I have found a free tool called TestDisk by CG Security, which seems to run on pretty much any operating system. The tool can be instructed to read the disk using arbitrary sector sizes, which means we can override the physical sector size reported by the drive and recover the data from it.

How to use

Having downloaded and installed this command-line utility, run it, make a decision about how any log files should be created, and then:

1. Select the disk from the list. Make sure you select the physical Disk rather than the logical Drive.
2. Select the Intel partition type.
3. Select the Geometry option and change Sector Size from 512 to 4096. This will allow TestDisk to read the disk properly.
4. Select Advanced which takes you to the file utilities, and - if there is more than one partition - select the partition you are interested in. You should also at this stage note-down the partition sizes, if you plan to rebuild the disk later.
5. Select List to view the files on the disk.
6. From here you can browse the file system, select individual files or groups of files, and copy them to another location (i.e. to a different disk).
7. To copy the whole disk, from the root directory, select a to select all files, then capital C to copy the selected files, then browse to the destination disk and press capital C again to copy all the files across.
8. Repeat if there are multiple partitions.

You have now made a backup of the whole disk! You can therefore use the standard operating system tools to wipe and repartition the original disk as per the previous layout (this will automatically use the correct geometry now that there is no disk enclosure translating the sectors) and copy the files back to complete the rebuild.

Note that the above instructions only restore the disk partitions and file structures but this may not be sufficient if you also need boot sectors, use non-NTFS drives, have files that need to be in particular disk locations (rare) or use other more sophisticated gubbins (e.g. alternative data streams). All of these issues may or may not be resolvable using this tool, but not with the above instructions.

---

(Note that I don't really want to have to accept this as the answer, as it is actually side-stepping my question rather than resolving it. However, I am noting it here as an alternative approach.)

Answer 2

It is possible to do this by creating partitions of the same size and in the same location using fdisk on Linux. You need to translate the start and end values based on the difference in sector sizes. It looks like the current values match the size of the disk (did the enclosure map the partition table too?) so you only need to fix the NTFS boot sector.

Filesystem metadata for FAT and NTFS depends on the disk sector size so you'll have to modify it. If the NTFS cluster size is smaller than 4K then it will not be possible to change in the 512 to 4096 direction.

If it's NTFS you can edit the boot sector (at the start of the partition) with hexedit on Linux changing the following little-endian values (instructions assume a 4K cluster size):

• 0x0B (Bytes per sector) 0x0200 (512) <-> 0x1000 (4096)
• 0x0D (Sectors per cluster) 0x08 (8 * 512 = 4096 byte clusters) <-> 0x01 (1 * 4096 = 4096 byte clusters)
• 0x1C (Hidden sectors) The number of sectors preceding the partition
• 0x28 (Total sectors) The partition size in sectors minus 1

Reference: NTFS Partition Boot Sector

If you were booting Windows 10 from this disk then you would need to preserve the disk and partition GUIDs. The EFI System Partition (FAT32) must be at least 33MB (normally 100MB) for a disk with 512 byte sectors and 257MB (normally 260MB) for a disk with 4096 byte sectors (I recommend just recreating it because it contains few files and is easy to copy).

Answer 3

You may want to consider trying to change the logical sector size on the disk interface to match the 4K sector size that was managed through the defunct USB interface:

hdparm --set-sector-size 4096 /dev/sdX    # for an appropriate value of X

You'll need a reasonably recent version of hdparm to find this option. I don't know if Ubuntu 15.4 is recent enough (and if not, you can maybe download a Live version).

Obligatory warning: I don't have a disk that is mangled in the same way for me to test this command.