Currently back to the state before the restart:
Current progress: 0%, 175848 file(s) found
Estimated time left: 12 days
Thanks,
Kevin
To be honest Kevin, I think you're going about it the wrong way. To run Recuva against a RAW partition, which is not supported (I'm surprised it actually runs) and to expect some relevant results, is rather optimistic. I would try to get the partition back to a recognised file organisation first. How can the timings be relevant?
But I might be proved wrong. I can't offer any advice as this is way into the unknown.
I was surprised to see this HDD has 3 recovery partitions,
and astounded by the "EFI System Partition".
Was this a GPT style formatted HDD ?
Is it possible to change the drive letter of the RAW partition ?
Has this HDD been used with any sort of Apple computer ?
I ask because I have read
As you can see, the partition is protected in such a way that even the powerful Disk Management tool cannot do anything to it. Note that it's not because the partition is EFI, it's because the tool that created that partition had marked it in a way that prohibits other tools to tamper with it. (That's usually the case for the system hard disks formatted on the Mac computers.)
https://www.winabili...disk-partition/
It occurs to me that when partition G:\ was either NTFS or FAT32,
then either EFI or Apple could prevent other tools from changing partitions on this HDD,
and might even prevent Windows from changing partition G: drive letter,
hence when the file system was changed perhaps the drive letter remained frozen at G:\ and could not be removed in the way that Windows would have wished.
It may be worth downloading a freeware ISO and burning a bootable Recovery CD for a Linux very of the HDD,
http://www.partition...m/download.html
N.B. My experience in the past was that this cannot change or even recognise drive letters because it was based on Linux,
but at least it will give you a different perspective.
Recuva depends on Windows and the assigned drive letter and Windows is obviously NOT working as it should.
It is predictable that Windows will not allow a drive letter to be allocated to a RAW partition,
and the fact that your Windows is NOT being predictable in its handling of your HDD suggests that when Recuva Searches G:\,
Windows could be feeding it data from any location on the drive.
Thanks Alan_B and Augeas.
To be honest Kevin, I think you're going about it the wrong way. To run Recuva against a RAW partition, which is not supported (I'm surprised it actually runs) and to expect some relevant results, is rather optimistic. I would try to get the partition back to a recognised file organisation first. How can the timings be relevant?
But I might be proved wrong. I can't offer any advice as this is way into the unknown.
Since Augeas suggested RAW is not supported by Recuva, I decided to try two other tools which do explicitly support RAW partitions -- iCare Data Recovery and Easeus Data Recovery Wizard. But the result was the same kind of slow performance -- multiple day wait times. So I gave up on those, as well.
From there, I sought some way to "get the partition back to a recognised file organisation" as Augeas suggested. I went with the testdisk routine available on the PartedMagic as described by James Litten.
When testdisk began showing multiple disk read errors, I took the advice to download and run a utility to test the health of the hard drive itself, namely HDTune.
The HDTune error scan on this disk shows massive damage, 70% damaged blocks in the first 4 GB, and still counting.
This escalates the disk's case beyond the scope of the Recuva forum, as my only hope at this point is to send in the disk to a professional recovery company. The data I'm trying to recover is probably not worth that expense.
Thanks again to everyone for your help and advice.
Kevin
Thanks for that Kevin: can't win them all.