2

I have a 4TB hard drive /dev/sdb, which has a formatted NTFS filesystem occupying the whole drive. It apparently has no partition table of any kind, or if it does, it is out of date or corrupted.

fdisk -l shows this:

Disk /dev/sdb: 4000.8 GB, 4000787030016 bytes
255 heads, 63 sectors/track, 486401 cylinders, total 7814037168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x2052474d

This doesn't look like a partition table
Probably you selected the wrong device.

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   ?     6579571  1924427647   958924038+  70  DiskSecure Multi-Boot
Partition 1 does not start on physical sector boundary.
/dev/sdb2   ?  1953251627  3771827541   909287957+  43  Unknown
Partition 2 does not start on physical sector boundary.
/dev/sdb3   ?   225735265   225735274           5   72  Unknown
Partition 3 does not start on physical sector boundary.
/dev/sdb4      2642411520  2642463409       25945    0  Empty

Partition table entries are not in disk order

gdisk -l says only an MBR partition table is present.

The drive works fine when running under Linux; I can mount /dev/sdb without issues. But I want to load the drive using an hard drive enclosure on a windows machine so that I can run chkdsk on it. Windows however sees this MBR as shown in fdisk, and shows 4 partitions, none of which are usable (none are even marked as NTFS).

Is it possible to simply write a partition table to this drive without changing the contents of the NTFS filesystem, so that Windows 7 can access it as a single partition occupying the whole drive? If so, how?

Edit: If it's not possible to simply write a partition table, is there some non-destructive method to accomplish the same goal of using the drive under Windows, perhaps by downsizing the file system by a few kilobytes and then writing a partition table? (ie, with gparted).

jtbr
  • 243

2 Answers2

4

In this particular situation you can't write MBR to this drive because you will loose all the data on it. The best way would be to copy all the data elsewhere and then partition the drive on Windows with diskmgmt.msc.

pbies
  • 3,550
0

In principle, you could do something like this:

  1. Use ntfsresize to shrink the existing filesystem by a small amount (in theory, 2081 sectors should be enough, but I'd do at least 2 MiB just to be safe).
  2. Shift the filesystem "into" the disk by some fixed amount. 1 MiB should be optimal. This is the tricky part, since you'd be reading from and writing to the same device, and it's imperative that this be done in a way that does not overwrite data before it's copied. In other words, you'd have to copy starting from the end of the filesystem, rather than the more common approach of doing it from the start. Offhand, I don't know of a tool that will do this, aside from partition-resizing tools like GParted -- and AFAIK, those tools all require that a partition table be present. A script that uses dd to do this would be possible, and not very hard to write, but it would require careful testing.
  3. Create a partition table on the disk along with a single partition that begins at the new start point for the filesystem and that ends where the filesystem ends.

Unless you can find a tool that will do step #2 with something resembling safety, copying the data off the disk, creating partitions, and then restoring the data, as pbies suggests, is likely to be the best solution. This may even be faster than trying to shift the whole filesystem, too, particularly if the filesystem is mostly empty. Even if you find a tool to do step #2 (or the whole procedure) in one go, I would strongly recommend creating a backup before proceeding, since the procedure I've outlined here is quite dangerous.

As a side comment, it sounds like you've been using this NTFS disk exclusively in Linux. You've discovered one compelling reason to not do this: Linux's NTFS maintenance tools are rudimentary at best. If you plan to access the data exclusively from Linux, I recommend you back up, create partition(s), create Linux-native filesystem(s), and restore the data to the new Linux-native filesystem(s). This will give you a better ability to repair filesystem damage from within Linux, without involving Windows.

Rod Smith
  • 22,290