[klinsmann]

Hi there everyone,

I've been going crazy over the past few days trying to recover my laptop's HDD. I read the whole thread regarding a similar problem on the same HDD model:

http://www.msfn.org/...w-vista-32-bit/

Problem is that I have a few partitions on that HDD, but I can only access one of them. This is basically my HDD's layout:

* RECOVERY partition (came with the laptop) > Accesible
* Windows 7 x64 partition (F:) > Shown as RAW, 137GB (partition is actually larger than those 137GB)
* Ubuntu partition (+ SWAP partition) > Not showing, don't care if it gets lost

Following the steps given by jaclaz I get to find the StartSector of each partition with PTview, but I don't know how to go on from there. I have already installed Tiny Hexer (+ scripts), HDHacker and DataRescueDD.

Testdisk won't let me access the W7 partition as no LBA48 support seems to be available for this HDD.

What should I do now? What info should I post here in order to solve this issue?

Any help will be MUCH appreciated, I will definitely try to help out from now on and become part of this community.

Thanks a lot

Edit: Added the PTview info on the HDD, and DataRescue DD + Tiny Hexer "Open drive..." screenshots

Attached File(s)

•  ptview.png (40.12K)
  Number of downloads: 8
•  hex.png (43.15K)
  Number of downloads: 8
•  drdd.png (51.3K)
  Number of downloads: 4

This post has been edited by klinsmann: 13 September 2012 - 05:27 PM

[jaclaz]

You are in a "peculiar" situation.
The number of sectors actually seen for \\.\PhysicalDrive1 is 268,435,455 that nicely corresponds to 137,438,952,960 bytes.

I.e., for *any* reason the disk drive "declares itself" as being that size in TOTAL.

What I would do is to image it "as is" with DatarescueDD.

Then I would try to recover the data that actually was in this "initial" 137 Gb.

The reason WHY could be almost *anything*, but I seem to remember to have read of disks behaving similar to this, I will have a look if I can find any related info.

To proceed, you need a disk with at least 500+140 Gb.
A 640 Gb disk is probably enough , but it's a bit "tight", best idea could be another 500 Gb hard disk + some 140/150 Gb free on another disk.
The general idea is:

• image the disk to a roughly 137 Gb image with DatarescueDD
  
• restore the image to a "new" 500 Gb disk
  
• fix the filesystem of the biggish NTFS partition and have back access to (hopefully) all the data physically residing on the first 137 GB

Once done that we will see if there is some form of "user doable" fix.

Please post some more info

• Which exact hard disk model is it?
  
• Which exact laptop is it?
  
• How/when did it happen?
  
• How are you accessing the disk currently? <- please not that IF you are using a USB to SATA or USB to IDE adapter or "external case", some (older ones) will "cut-off" at the 28 bit LBA address (strangely similar to 137 Gb )

jaclaz

[klinsmann]

Let's try and answer all the questions:

jaclaz, on 14 September 2012 - 02:41 AM, said:

You are in a "peculiar" situation.
The number of sectors actually seen for \\.\PhysicalDrive1 is 268,435,455 that nicely corresponds to 137,438,952,960 bytes.

I.e., for *any* reason the disk drive "declares itself" as being that size in TOTAL.

What I would do is to image it "as is" with DatarescueDD.

Then I would try to recover the data that actually was in this "initial" 137 Gb.

The reason WHY could be almost *anything*, but I seem to remember to have read of disks behaving similar to this, I will have a look if I can find any related info.

Image saved and I already managed to save all the necessary info on those 137 GB. I'm guessing the missing data will be located on the "ghost" sectors on that partition.

jaclaz, on 14 September 2012 - 02:41 AM, said:

To proceed, you need a disk with at least 500+140 Gb.
A 640 Gb disk is probably enough , but it's a bit "tight", best idea could be another 500 Gb hard disk + some 140/150 Gb free on another disk.
The general idea is:

• image the disk to a roughly 137 Gb image with DatarescueDD
  
• restore the image to a "new" 500 Gb disk
  
• fix the filesystem of the biggish NTFS partition and have back access to (hopefully) all the data physically residing on the first 137 GB

Once done that we will see if there is some form of "user doable" fix.

No problem about that, I have a 1TB drive I can use for this purpose (is it OK if I just use this one?).

jaclaz, on 14 September 2012 - 02:41 AM, said:

Please post some more info

• Which exact hard disk model is it?
  
• Which exact laptop is it?
  
• How/when did it happen?
  
• How are you accessing the disk currently? <- please not that IF you are using a USB to SATA or USB to IDE adapter or "external case", some (older ones) will "cut-off" at the 28 bit LBA address (strangely similar to 137 Gb )

jaclaz

1. HDD is a Seagate ST950032 5AS (2.5" SATA drive)
2. Laptop is an ASUS-X52J (Core i5)
3. This happened last friday, I started looking for solutions on monday and so far I've managed to save 137 GB of data (which counts for about 60-70% of the vital data stored on that drive).
4. I am currently accesing the drive through a USB to SATA adapter connected to a desktop PC with Windows 7. Tried connecting the drive directly into the PC motherboard through SATA but the LBA48 issue with TestDisk was still there.

Thanks jaclaz, let me know what else you might need

[jaclaz]

klinsmann, on 14 September 2012 - 12:21 PM, said:

No problem about that, I have a 1TB drive I can use for this purpose (is it OK if I just use this one?).

Sure, that should do nicely. (of course all data - if any - currently on the 1 Tb disk will be lost)
If you need help to dd the 137 Gb image to the disk, ask, but if you use dsfi (part of the dsfok toolkit):
http://members.ozema...eezip/freeware/
it should be easy unless the Windows 7 - for any reason - creates issues.
Be VERY careful about WHICH PhysicalDrive n to use AND be aware that the dsfi (being a complement to dsfo) uses a "reversed" logic in command line:

Quote

dsfi DESTINATION Offset Size SOURCE

i.e.

Quote

dsfi \\.\PhysicalDriven 0 0 <Path>\my137Gb.img

klinsmann, on 14 September 2012 - 12:21 PM, said:

2. Laptop is an ASUS-X52J (Core i5)

Good, it should be a "normal" BIOS (seeing the disk as having 255x63 HS geometry) the issue would have been if the BIOS )like many HP's and Lenovo) see the disk internally connected as 240x63 (the USB connected are always seen as 255x63).

jaclaz

[klinsmann]

jaclaz, on 14 September 2012 - 01:03 PM, said:

klinsmann, on 14 September 2012 - 12:21 PM, said:

No problem about that, I have a 1TB drive I can use for this purpose (is it OK if I just use this one?).

Sure, that should do nicely. (of course all data - if any - currently on the 1 Tb disk will be lost)
If you need help to dd the 137 Gb image to the disk, ask, but if you use dsfi (part of the dsfok toolkit):
http://members.ozema...eezip/freeware/
it should be easy unless the Windows 7 - for any reason - creates issues.
Be VERY careful about WHICH PhysicalDrive n to use AND be aware that the dsfi (being a complement to dsfo) uses a "reversed" logic in command line:

Quote

dsfi DESTINATION Offset Size SOURCE

i.e.

Quote

dsfi \\.\PhysicalDriven 0 0 <Path>\my137Gb.img

klinsmann, on 14 September 2012 - 12:21 PM, said:

2. Laptop is an ASUS-X52J (Core i5)

Good, it should be a "normal" BIOS (seeing the disk as having 255x63 HS geometry) the issue would have been if the BIOS )like many HP's and Lenovo) see the disk internally connected as 240x63 (the USB connected are always seen as 255x63).

jaclaz

So basically, once this is done I should have full access to the "first" 137 GB and we'll work on how to access the rest of the data, am I right?

[jaclaz]

klinsmann, on 14 September 2012 - 01:22 PM, said:

So basically, once this is done I should have full access to the "first" 137 GB and we'll work on how to access the rest of the data, am I right?

Basically, yes.
The issue may be that it is possible (a number of factors are involved) that the NTFS filesystem driver will "choke" on partial data (or when you try accessing files that are not there) and force or require a NTFSCHK.
It is possible that you will need anyway to run TESTDISK on the "newly made" disk to fix the second copy of the bootsector, but I seem to remember that it won't be needed.

Once you (hopefully) got back the "main" files (the ones within the first 137 Gb imaged), and ONLY then, we will try to see what can be done on the original HD.

A guess (educated , but still a guess) could be that *somehow* the original disk "self-capped" to 137 Gb.
It is something that can happen "generically", I haven't been able to find substantial reports about this issue affecting particularly this specific disk model.

You can try using this:
http://blog.atola.co...drive-capacity/
I think that the disk must be connected "directly" (NOT through the USB converter) for this kind of tools to work.
The above is a "simplified" user friendly specific tool, a "pro" would most probably use HDAT2:
http://www.hdat2.com/
or a similar "lower level" tool, but the good thing is that the Atola tool will either work or fail completely, but shouldn't make things worse if it fails.

jaclaz

[klinsmann]

jaclaz, on 15 September 2012 - 02:38 AM, said:

klinsmann, on 14 September 2012 - 01:22 PM, said:

So basically, once this is done I should have full access to the "first" 137 GB and we'll work on how to access the rest of the data, am I right?

Basically, yes.
The issue may be that it is possible (a number of factors are involved) that the NTFS filesystem driver will "choke" on partial data (or when you try accessing files that are not there) and force or require a NTFSCHK.
It is possible that you will need anyway to run TESTDISK on the "newly made" disk to fix the second copy of the bootsector, but I seem to remember that it won't be needed.

Once you (hopefully) got back the "main" files (the ones within the first 137 Gb imaged), and ONLY then, we will try to see what can be done on the original HD.

A guess (educated , but still a guess) could be that *somehow* the original disk "self-capped" to 137 Gb.
It is something that can happen "generically", I haven't been able to find substantial reports about this issue affecting particularly this specific disk model.

You can try using this:
http://blog.atola.co...drive-capacity/
I think that the disk must be connected "directly" (NOT through the USB converter) for this kind of tools to work.
The above is a "simplified" user friendly specific tool, a "pro" would most probably use HDAT2:
http://www.hdat2.com/
or a similar "lower level" tool, but the good thing is that the Atola tool will either work or fail completely, but shouldn't make things worse if it fails.

jaclaz

I will let you know how this works out, I've been quite busy over the weekend

[klinsmann]

So, I finally found the time to fully get into this and get it solved ASAP.

I imaged the disk with DataRescue DD, however the images is a .dd file. How can I turn it into a .img? I have saved almost everything in those 137 GB, but as you predicted, some partial data is damaged (a few random files are shown as corrupted).

This is how I've set up the PC for the process: a 1 TB SATA Hard Drive connected through USB, and the "corrupted" Hard Drive we are trying to save directly plugged into the MB. Is that alright?

What should I do now?

Edit: Forgot to ask, what's the safest way to know which PhysicalDrive is the 1 TB drive I'll be using with dsfi?

This post has been edited by klinsmann: 21 September 2012 - 05:20 AM

[jaclaz]

klinsmann, on 21 September 2012 - 04:08 AM, said:

I imaged the disk with DataRescue DD, however the images is a .dd file. How can I turn it into a .img? I have saved almost everything in those 137 GB, but as you predicted, some partial data is damaged (a few random files are shown as corrupted).

Well, what most people tend to confuse is file format with file extension.
What you made with datarescue.dd is a RAW (file format) image, i.e. an exact, byte-by-byte, sector-by-sector, image of the source hard disk.
You can give it *any* name, and as well *any* extension, like .dd or .img, it will still remain a RAW image.
If you prefer the extension given to a filename has two scopes:

• be a "mnemonic" to quickly know what file format it is (of course only useful if you give appropriate extensions)
  
• be useful for associating those files to a given program

for all it matters you could name the image mynicespreadsheet.xls (only Excel will choke if you attempt double clicking on the file ).

klinsmann, on 21 September 2012 - 04:08 AM, said:

This is how I've set up the PC for the process: a 1 TB SATA Hard Drive connected through USB, and the "corrupted" Hard Drive we are trying to save directly plugged into the MB. Is that alright?

Which process?
If you dd the 137 Gb image to the 1 Tb disk you need NOT the original disk connected.
On the other hand if you already recovered most of the files from the "capped" hard disk or from the dd image, you may want to "skip" this part (you already have the image, so if needed you can do this later) and check just the "failed" disk with the Atola tool.
Unless *somehow* we change something in the failed disk, the accessible data will still remain the 137 Gb you already imaged.
"Restoring" the dd image to the "new" disk is simply an approach that allows the use of CHKDSK and TESTDISK on a "full sized" space, which may (or may not) help to fix the filesystem/access the files IF you did not managed to already save them (anything beyond the image size will remain anyway "a suffusion of yellow").

klinsmann, on 21 September 2012 - 04:08 AM, said:

Edit: Forgot to ask, what's the safest way to know which PhysicalDrive is the 1 TB drive I'll be using with dsfi?

Easiest?
Create a small partition on the disk and format it.
Open tiny hexer, FIle->Disk->Open Drive, you wil normally see something like (example):

Quote

\\.\PHYSICALDRIVE0
\\.\C: (PHYSICALDRIVE0, Partition 1)
\\.\PHYSICALDRIVE1
\\.\D: (PHYSICALDRIVE1, Partition 1)

The right PHYSICALDRIVE is the "parent" of the drive letter assigned to the newly created partition.

jaclaz

[klinsmann]

jaclaz, on 21 September 2012 - 05:50 AM, said:

klinsmann, on 21 September 2012 - 04:08 AM, said:

I imaged the disk with DataRescue DD, however the images is a .dd file. How can I turn it into a .img? I have saved almost everything in those 137 GB, but as you predicted, some partial data is damaged (a few random files are shown as corrupted).

Well, what most people tend to confuse is file format with file extension.
What you made with datarescue.dd is a RAW (file format) image, i.e. an exact, byte-by-byte, sector-by-sector, image of the source hard disk.
You can give it *any* name, and as well *any* extension, like .dd or .img, it will still remain a RAW image.
If you prefer the extension given to a filename has two scopes:

• be a "mnemonic" to quickly know what file format it is (of course only useful if you give appropriate extensions)
  
• be useful for associating those files to a given program

for all it matters you could name the image mynicespreadsheet.xls (only Excel will choke if you attempt double clicking on the file ).

So that's done

jaclaz, on 21 September 2012 - 05:50 AM, said:

klinsmann, on 21 September 2012 - 04:08 AM, said:

This is how I've set up the PC for the process: a 1 TB SATA Hard Drive connected through USB, and the "corrupted" Hard Drive we are trying to save directly plugged into the MB. Is that alright?

Which process?
If you dd the 137 Gb image to the 1 Tb disk you need NOT the original disk connected.
On the other hand if you already recovered most of the files from the "capped" hard disk or from the dd image, you may want to "skip" this part (you already have the image, so if needed you can do this later) and check just the "failed" disk with the Atola tool.
Unless *somehow* we change something in the failed disk, the accessible data will still remain the 137 Gb you already imaged.
"Restoring" the dd image to the "new" disk is simply an approach that allows the use of CHKDSK and TESTDISK on a "full sized" space, which may (or may not) help to fix the filesystem/access the files IF you did not managed to already save them (anything beyond the image size will remain anyway "a suffusion of yellow").

By "the process" I meant this whole thing. OK, so original Hard Drive is right now disconnected.

jaclaz, on 21 September 2012 - 05:50 AM, said:

klinsmann, on 21 September 2012 - 04:08 AM, said:

Edit: Forgot to ask, what's the safest way to know which PhysicalDrive is the 1 TB drive I'll be using with dsfi?

Easiest?
Create a small partition on the disk and format it.
Open tiny hexer, FIle->Disk->Open Drive, you wil normally see something like (example):

Quote

\\.\PHYSICALDRIVE0
\\.\C: (PHYSICALDRIVE0, Partition 1)
\\.\PHYSICALDRIVE1
\\.\D: (PHYSICALDRIVE1, Partition 1)

The right PHYSICALDRIVE is the "parent" of the drive letter assigned to the newly created partition.

jaclaz

I seem to be having an issue I did not have last time I used Tiny Hexer (check atteached image).

Thanks (as usual) jaclaz!

Edit: dsfi is denying acess when I try dsfi \\.\e: 0 0 SOURCE (SOURCE being of course the actual source file I renamed to .img)

Attached File(s)

•  asd.png (21.1K)
  Number of downloads: 3

This post has been edited by klinsmann: 21 September 2012 - 06:42 AM

[jaclaz]

klinsmann, on 21 September 2012 - 06:19 AM, said:

Edit: dsfi is denying acess when I try dsfi \\.\e: 0 0 SOURCE (SOURCE being of course the actual source file I renamed to .img)

That's an actual stupid thing of Windows Vista and later that - probably for the first time - turned around as a good thing .
You imaged a DISK (or \\.\PhysicalDrive) you have to restore the image to a DISK (or \\.\PhysicalDrive) NOT to a DRIVE (or \\.\LogicalDrive).

In my example:

Quote

\\.\PHYSICALDRIVE0
\\.\C: (PHYSICALDRIVE0, Partition 1)
\\.\PHYSICALDRIVE1
\\.\D: (PHYSICALDRIVE1, Partition 1)

you use the line with the RED drive letter to identify the GREEN parent and you supply it (the parent or the GREEN BOLDED one) to dsfi....

• DISK=PhysicalDrive=bigger container=starts at absolute sector 0 LBA=what you see in Disk management in the lower pane, on the left
  
• DRIVE=LogicalDrive=Primary Partition (or Logical Drive inside Extended Partition) contained inside DISK=starts at whatever sector is addressed for it in the MBR or in the EPBR=what you see in the top pane in Disk Management (and has normally a Drive letter assigned or in the lower pane on the right as part of the DISK

The good MS guys made their best to confuse the matter, rest assured that you are not the first one (and unfortunately not even the last one ) to fall for this misunderstanding.

jaclaz

This post has been edited by jaclaz: 21 September 2012 - 07:18 AM

[klinsmann]

jaclaz, on 21 September 2012 - 07:17 AM, said:

klinsmann, on 21 September 2012 - 06:19 AM, said:

Edit: dsfi is denying acess when I try dsfi \\.\e: 0 0 SOURCE (SOURCE being of course the actual source file I renamed to .img)

That's an actual stupid thing of Windows Vista and later that - probably for the first time - turned around as a good thing .
You imaged a DISK (or \\.\PhysicalDrive) you have to restore the image to a DISK (or \\.\PhysicalDrive) NOT to a DRIVE (or \\.\LogicalDrive).

In my example:

Quote

\\.\PHYSICALDRIVE0
\\.\C: (PHYSICALDRIVE0, Partition 1)
\\.\PHYSICALDRIVE1
\\.\D: (PHYSICALDRIVE1, Partition 1)

you use the line with the RED drive letter to identify the GREEN parent and you supply it (the parent or the GREEN BOLDED one) to dsfi....

• DISK=PhysicalDrive=bigger container=starts at absolute sector 0 LBA=what you see in Disk management in the lower pane, on the left
  
• DRIVE=LogicalDrive=Primary Partition (or Logical Drive inside Extended Partition) contained inside DISK=starts at whatever sector is addressed for it in the MBR or in the EPBR=what you see in the top pane in Disk Management (and has normally a Drive letter assigned or in the lower pane on the right as part of the DISK

The good MS guys made their best to confuse the matter, rest assured that you are not the first one (and unfortunately not even the last one ) to fall for this misunderstanding.

jaclaz

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that?

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Edit: Problem solved!

This post has been edited by klinsmann: 21 September 2012 - 07:52 AM

[jaclaz]

klinsmann, on 21 September 2012 - 07:21 AM, said:

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that?

Cannot say.
Another "queer" behaviour of Winddows 7?

klinsmann, on 21 September 2012 - 07:21 AM, said:

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Post a screenshot of Disk Management...

jaclaz

[klinsmann]

jaclaz, on 21 September 2012 - 07:47 AM, said:

klinsmann, on 21 September 2012 - 07:21 AM, said:

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that?

Cannot say.
Another "queer" behaviour of Winddows 7?

klinsmann, on 21 September 2012 - 07:21 AM, said:

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Post a screenshot of Disk Management...

jaclaz

Managed to solve this just as you replied. dsfi working as we speak, "new" disk should be ready in 20-30 minutes

This post has been edited by klinsmann: 21 September 2012 - 08:06 AM

[klinsmann]

klinsmann, on 21 September 2012 - 07:50 AM, said:

jaclaz, on 21 September 2012 - 07:47 AM, said:

klinsmann, on 21 September 2012 - 07:21 AM, said:

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that?

Cannot say.
Another "queer" behaviour of Winddows 7?

klinsmann, on 21 September 2012 - 07:21 AM, said:

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Post a screenshot of Disk Management...

jaclaz

Managed to solve this just as you replied. dsfi working as we speak, "new" disk should be ready in 20-30 minutes

So that's done! I now have the 1 TB drive with the .dd image on it. I've run CHKDSK /F on that drive, and I've managed to access the data on that drive. So far Windows 7 is letting me access the data but not letting me copy it to another drive. I've attached a screenshot of how the 1 TB drive looks like right now.

This is looking good, what's next?

Attached File(s)

•  easeus.png (8.1K)
  Number of downloads: 4

[jaclaz]

klinsmann, on 21 September 2012 - 09:43 AM, said:

So that's done! I now have the 1 TB drive with the .dd image on it. I've run CHKDSK /F on that drive, and I've managed to access the data on that drive. So far Windows 7 is letting me access the data but not letting me copy it to another drive. I've attached a screenshot of how the 1 TB drive looks like right now.

This is looking good, what's next?

Run CHKDSK /R

Then, try accessing the disk with TESTDISK.
The partition should show "normally" (it might protest about the backup of the bootsector, but that is irrelevant), then by pressing "p" you should be able to access (and copy) files (with "c").

You most probably cannot access the files directly because of NTFS permissions, since we are into "living dangerously" you can try faking to be "System", here:
http://reboot.pro/17501/
try using RunasSystem to launch a file manager (like 7-zip) or a command console and see if you can copy the files to another disk (or you may create another partition on the rest of the 1 Tb disk)..

jaclaz

[klinsmann]

jaclaz, on 21 September 2012 - 10:12 AM, said:

klinsmann, on 21 September 2012 - 09:43 AM, said:

So that's done! I now have the 1 TB drive with the .dd image on it. I've run CHKDSK /F on that drive, and I've managed to access the data on that drive. So far Windows 7 is letting me access the data but not letting me copy it to another drive. I've attached a screenshot of how the 1 TB drive looks like right now.

This is looking good, what's next?

Run CHKDSK /R

Then, try accessing the disk with TESTDISK.
The partition should show "normally" (it might protest about the backup of the bootsector, but that is irrelevant), then by pressing "p" you should be able to access (and copy) files (with "c").

You most probably cannot access the files directly because of NTFS permissions, since we are into "living dangerously" you can try faking to be "System", here:
http://reboot.pro/17501/
try using RunasSystem to launch a file manager (like 7-zip) or a command console and see if you can copy the files to another disk (or you may create another partition on the rest of the 1 Tb disk)..

jaclaz

CHKDSK /R has taken a while, it's been deleting register segments and some other stuff I don't really understand.

TestDisk is working alright, so the backup is on its way (or at least it looks like it is).

Now I'm guessing we're done with the "easy" part, is there a chance for me to recover the rest of the data on the "original" drive (the 500 GB one)?

This post has been edited by klinsmann: 21 September 2012 - 10:54 AM

[jaclaz]

klinsmann, on 21 September 2012 - 10:53 AM, said:

Now I'm guessing we're done with the "easy" part, is there a chance for me to recover the rest of the data on the "original" drive (the 500 GB one)?

Yep, that's the tricky part.
See what the Atola tool has to say, first thing (remember that it is just a "semi-random guess" that the drive self-capped ).
http://blog.atola.co...drive-capacity/
whether tool will work under 7 and particularly under 7 x64 is up to you to find out.

jaclaz

[klinsmann]

jaclaz, on 21 September 2012 - 11:12 AM, said:

klinsmann, on 21 September 2012 - 10:53 AM, said:

Now I'm guessing we're done with the "easy" part, is there a chance for me to recover the rest of the data on the "original" drive (the 500 GB one)?

Yep, that's the tricky part.
See what the Atola tool has to say, first thing (remember that it is just a "semi-random guess" that the drive self-capped ).
http://blog.atola.co...drive-capacity/
whether tool will work under 7 and particularly under 7 x64 is up to you to find out.

jaclaz

OK, so I managed to make the Atola tool work (had to try on a 32-bit version of Windows 7). Things seem to be getting trickier by the minute...

Attached File(s)

•  Sin título.png (21.85K)
  Number of downloads: 4

[jaclaz]

klinsmann, on 21 September 2012 - 11:39 AM, said:

OK, so I managed to make the Atola tool work (had to try on a 32-bit version of Windows 7). Things seem to be getting trickier by the minute...

Hmmm.
It is possible that the tool (being a bit old) simply does not compute the 500 Gb size.
As a matter of fact (I am notoriously an optimist ) it could be a good sign that a diffference (even if negative) is found between "declared" and "actual" capacity.

When the going gets tough...
http://en.wikipedia....Tough_Get_Going

Can you (in the sense you know how to) make a DOS bootable flopppy image (and from it a CD-ROM, as I presume you haven't a floppy dirve on that machine)?
Or a bootable USB stick?

If yes, start getting this:
http://www.hdat2.com/

If no, post what you have available and any doubts you may have in creating a DOS bootable environment.

And/or get MHDD instead (it does come as a bootable .iso):
http://hddguru.com/s...005.10.02-MHDD/

jaclaz