Hi Al.

We started this conversation here:

http://lists.gnu.org/archive/html/bug-ddrescue/2009-07/msg00029.html
and
http://lists.gnu.org/archive/html/bug-ddrescue/2009-07/msg00033.html

I don't know about the fdisk -l rule. I would think that it depends on whether the kernel can see the drive or not. Drives are more analog than we think. Sometimes a drive which keeps resetting itself may need several attempts before you can start to image it - like starting a gas-powered lawnmower. I have had success with rapidly retrying to start ddrescue on the drive until it "catches" as I mentioned on the ddrescue-mailing list. Hitting cursor-up at the command-line prompt repeates the last command.

So to better describe what I do, I run

tail - f /var/log/messages

to keep a continuous view of the kernel messages. This allows me to see whether the drive is alive and whether the kernel is able to use it or not. In another console, I run

sudo ddrescue /dev/whatever image log

If it is unable to use the device, I can try ddrescue several times per second for about a minute. After that, I may try power cycling the drive to see if that changes anything. I usually end up being able to image the drive and I always treat each time I start an image as if it were the last time the drive will function. In that respect, I am properly set up in a cool environment with a proper UPS.

Is Ubuntu Rescue Remix better? Well, it's the same kernel and it uses the same stack to access the hardware. The only difference between the Rescue-Remix and the Desktop is that Gnome-Volume-Manager is not running. So your drive will not automatically be mounted. Maybe that can interfere with an attempt to image the drive?

Also, I don't understand what you are saying about getdataback. As I understand it, it's a file carver. In what circumstance has it been able to see these drives where they don't appear in a Linux environment?

Andrew

"Well I dont have the disk anymore, but suffice to say that eventually I did get ddrescue to run and recognise the disk BUT it simply recognised the disk as "one big error" and recovered 0 data!! (with -v -n)"

1. I never use -n unless I am in a big rush.
2. I reckon your drive died.

"Getdataback allow me to copy off the most important files....what more do you want to know about the circimstances?"

I don't see how a file carver could work on a failing drive - that's the whole reason to image a drive. You eliminate the read errors by imaging, then get around the holes in the filesystem by file carving. And did you run this after you tried gddrescue?

i have a similar problem.
http://ubuntuforums.org/showthread.php?t=1385089
you suggest to wait and you're right.
i was trying to write a script that trigger ddresucue when the kernel find the drive.
how can i know to what dev invoke ddrescue?

Keep looking at /var/log/messages.

If the partition table is read, then you may have success at getting some data off the drive. Try waiting a few minutes and then power cycling the drive if nothing comes up.

In this case, I think the kernel is recognizing your drive's interface, but not the drive itself. Which is why you are getting 0 bytes. That happens to me when I blow out a power supply - the drive dissapears and the recovery stops (it knows to check to see if the device is still there). If I try to restart the recovery, it will detect a drive of 0 bytes and end successfully.