I recently bought a new internal hard disk (SeaGate 2TB Barracuda) but since I had no room inside my case for another HDD, I decided to format it (2 partitions of approx. 900 GB each) via an external enclosure connected via usb, then transferred all my data to it. Once I got rid of my old disks, I removed the new one from the external enclosure and mounted it conventionally inside my case.
Here's where the trouble begins. When I boot up, Windows (7, 64 bit) gives me a Disk Not Formatted error. If I go to Disk Management, it shows 2 partitions of about 115 GBs each, and 1.6 TBs of unallocated space. This makes no sense since I formatted 2 partitions of 900 GBs, and transferred 1.2 TBs between the 2 of them.
And when I remove the disk from my PC and place it back inside the enclosure, it once again sees the 2 partitions and all the data that I transferred to them without any problems.
Now, I know for a fact that there's nothing wrong with the sata slots on my motherboard or the PSU cables since my previous disks ran fine. I also know that there's nothing wrong with the disk itself since it runs fine when within the external enclosure. This leads me to believe that there's a difference between formatting a disk on the motherboard and within an external enclosure and that that's what's causing the problem.
I'm basically wondering if there's a way to solve this without having to reformat the disk and lose the data on it.
ps: if you're wondering why I don't just start from scratch, my new hard disk is now the only place I have this data on, with no where to possibly transfer it to temporarily while I reformat it.
Seagate's GoFlex drives use 4KB LBAs rather than 512-bytes. The USB-SATA bridge IC inside the enclosure converts the 4KB LBAs to eight 512-byte sectors before passing them on to the HDD.
When accessed via USB, Windows (including Win XP) has no problem dealing with 4KB LBAs. That's because the drive is treated as a USB mass storage device. However, when the drive is installed internally, this exposes the drive's 512-byte LBAs, so Windows can no longer see the file system.
If you examine sector 0 with a disc editor, I can show you exactly what is happening.
I wasn't able to get a SIout.txt though. Running it normally without privileges just returned a text file with 'Access Denied' under each disk entry, and marking secinspect.exe to run as admin in its properties would cause a command prompt to briefly pop up with scrolling hexadecimal values, but nothing but the date would be written to SIout.txt.
Anyway, I downloaded the programmes you suggested, and tried looking around with DM Disk Editor and Data Recovery (DMDE). I tried comparing my working system disk and my 2TB one, but I didn't feel comfortable modifying anything since I wasn't too sure where to even look.
This is what my working system disk looks like:
And this is what my flawed 2TB disk looks like:
I don't really understand much in all that, so if I could ask for a bit of a walkthrough for dummies here, that would be great!
This confirms that when the HDD is installed inside the computer, its LBA size is 512 bytes.
LBA 0 contains the drive's partition table. It is showing two NFTS partitions.
The first partition begins at LBA 256 and has a size of 245178112 LBAs.
The second partition begins at LBA 245178368 and has a size of 243199744 LBAs.
DMDE computes the partition sizes in GB by assuming that the LBA size is 512 bytes. This gives 126GB/117GiB and 125GB/116GiB, respectively.
However, this is incorrect since the LBA size inside the enclosure is actually 4096 bytes.
At the bottom of the screenshot, DMDE displays the locations and sizes of all the partitions it has actually discovered. The bold partitions represent those which appear in the current partition table, and the others are those which may have existed at an earlier time. An NTFS volume starts with a boot sector and finishes with a backup boot sector.
If we take the first partition as an example, the partition table is telling us that it begins at LBA 256. However, DMDE is telling us that there is no boot sector at LBA 256 (there is an X through the volume). Instead DMDE has found a boot sector at LBA 2048 (= 256 x 8). So this proves that LBA 256 inside the enclosure is equivalent to LBA 2048 outside the enclosure. Notice that the partition sizes also differ by a factor of 8.
If you re-examine the same drive inside the enclosure, all the numbers will correctly reflect the 4KB LBA size.
If your data are not important, then just delete the partitions, and reinitialise and reformat your drive.
Otherwise, if you wish to preserve your data, then this would require a lot more work, assuming it were even feasible. For a start, the partition's boot sector would need to be edited as well. The bottom line is that I have no idea how to go about the task.
Ah, I see. I guess I'll first have to find somewhere to backup my data to. I currently don't have enough spare space, which is why I was hoping there would be some kind of a fix to this. Does sound quite complicated though.