Reading Apple Files with a Windows Machine?

Boris wrote:
Paul wrote in news
Huge snip


Well, if you absolutely cannot get the table with smartctl
in Linux, go back to windows and use the Health tab
of HDTune 2.55.

http://www.hdtune.com/files/hdtune_255.exe

While Linux could be mis-interpreting some parameters
in SMART, it's possible the disk itself has some way
of indicating imminent failure after "doing the short
test" on its own. It could be a failure indicated by
short test, rather than an analysis of the SMART
parameter table to reach the same conclusion.

You really need to get working on your ddrescue/gddrescue.
And try and get as much data off the disk as possible.
Perhaps the active surface of the disk is toast, but
you'll discover that when you try. The thing is, the
disk would not have responded, unless the disk heads
loaded and the controller was able to read the
Service Area. So *some* portion of the platters
is readable. But we don't know how much.

Paul


I ran HDTune 2.55 a few weeks ago with the MAC HD USB tethered. The
results we

https://postimg.cc/gallery/25g6b1tdo/

The Health Tab displayed nothing for the MAC HD..

At the same time, to be sure HDTune was working correctly, I applied
HDTune 2.55 to my Windows OS disk, and it reported ok on all tabs but the
Health Tab, which displayed nothing.

Yesterday, with the MAC HD connected directly to the SATA motherboard
connection, HDTune recognized all drives on my system, except for the MAC
HD.

I'm not going to dick around any longer trying to get S.M.A.R.T. dats.

I'm going to see what I can do with imaging the MAC HD to another hard
drive.


It should have worked.

But ddrescue is where you have to go, and quickly.

The details don't matter any more, just the objective matters.
Save the sectors before it is too late.

Paul

Boris wrote:
Paul wrote in news
Boris wrote:
Paul wrote in news
Huge snip


Well, if you absolutely cannot get the table with smartctl
in Linux, go back to windows and use the Health tab
of HDTune 2.55.

http://www.hdtune.com/files/hdtune_255.exe

While Linux could be mis-interpreting some parameters
in SMART, it's possible the disk itself has some way
of indicating imminent failure after "doing the short
test" on its own. It could be a failure indicated by
short test, rather than an analysis of the SMART
parameter table to reach the same conclusion.

You really need to get working on your ddrescue/gddrescue.
And try and get as much data off the disk as possible.
Perhaps the active surface of the disk is toast, but
you'll discover that when you try. The thing is, the
disk would not have responded, unless the disk heads
loaded and the controller was able to read the
Service Area. So *some* portion of the platters
is readable. But we don't know how much.

Paul

I ran HDTune 2.55 a few weeks ago with the MAC HD USB tethered. The
results we

https://postimg.cc/gallery/25g6b1tdo/

The Health Tab displayed nothing for the MAC HD..

At the same time, to be sure HDTune was working correctly, I applied
HDTune 2.55 to my Windows OS disk, and it reported ok on all tabs but
the
Health Tab, which displayed nothing.

Yesterday, with the MAC HD connected directly to the SATA motherboard
connection, HDTune recognized all drives on my system, except for the
MAC
HD.

I'm not going to dick around any longer trying to get S.M.A.R.T. dats.

I'm going to see what I can do with imaging the MAC HD to another hard
drive.

It should have worked.

But ddrescue is where you have to go, and quickly.

The details don't matter any more, just the objective matters.
Save the sectors before it is too late.

Paul

So the next step was to try ddrescue. I remembered Frank Slootweg (in
this thread 7/6/2018) warning that:

"sda and sdb dependent on the sequence in which you connect the
original disk and the to-be-copied-to disk?"

I tested this, and discovered this is true, that the device designation is
dependent on order of connection. With internal, USB flash, and USB
external drives attached, the sdX designations were different than if only
the two disks I wanted to use were connected. Also, the designations were
different depending on the order of connection. I guess Linux orders them
in order of discovery.

I disconnected all disks (including the Win7 OS disk, not wanting to blow
it up in error) and loaded up Knoppix. I then connected the MAC HD and a
new Western Digital Passport 1TB HD.

MAC HD = sda (source, 500GB)
Passport HD = sdf (destination, 1TB)

Linusx Disks told me that the Passport drive was mounted at /media/sdf1

I tried to run ddrescue with a log file, but couldn't get the syntax
correct, or maybe I did, but here's the results:


knoppix@Microknoppix:~$ ddrescue -f /dev/sda /dev/sdf /media/sdf1
ddrescue: Mapfile exists and is not a regular file.
knoppix@Microknoppix:~$ ddrescue -f /dev/sda /dev/sdf
GNU ddrescue 1.22
ipos: 500107 MB, non-trimmed: 0 B, current rate: 0 B/s
opos: 500107 MB, non-scraped: 0 B, average rate: 0 B/s
non-tried: 0 B, bad-sector: 500107 MB, error rate: 17313 kB/s
rescued: 0 B, bad areas: 1, run time: 2h 55m 25s
pct rescued: 0.00%, read errors:984404307, remaining time: n/a
time since last successful read: n/a
Finished
knoppix@Microknoppix:~$


For the first few minutes, there was a line that said someting about
Trials 5. I thought this would last till the end of the run, but it
disappeared shortly, so I wasn't able to copy/paste it here.

I then logged on to the Passport drive...no changes.

Boris

The mapfile should be a text file, not a partition.

You transfer a whole-disk-identifier to a whole-disk-identifier,
to do device to device cloning. You got that part right.

/dev/sda /dev/sdf

The third item in the list, should be a text file. Perhaps that's
the map file they refer to.

All I have here at the moment to test with is:

KNOPPIX_V8.1-2017-09-05-EN.iso 4,553,826,304 bytes

Which one do you have ?

The package likely comes from Debian, and you could check
your version of ddrescue as well. Mine is "version 1.22
of GNU ddrescue".

ddrescue -V

I doubt it's highly sensitive to version, but I don't
want to wander too far off target.

And you have the basic form right, except the mapfile.

ddrescue -f /dev/sda /dev/sdf ~/mymapfile.txt

You can use "whoami" to check what account you
are using currently. On Knoppix, this is likely
"root", so sudo is not needed. On Ubuntu, you
would use...

sudo ddrescue -f /dev/sda /dev/sdf ~/mymapfile.txt

**********

ddrescue can copy from a device to a device, a device to an image file,
an image file to a device. In this example (one I tested), I transferred
a device to an image file.

sudo ddrescue -S -b8M /dev/sdb /mount/external/backup/sdb.raw /mount/external/backup/sdb.log

The -S in that example, makes "sdb.raw" a "sparse" file, which
means that sectors full of zeros need not be recorded using
disk surface. Instead, a table of present or missing sectors
is kept, to conserve space. This only makes sense for disks
that are mostly full of zeros to start with. Normal disks
don't have an excess of sectors-full-of-zeros, so this -S
option will not help you.

The -b8M on the version I was using, was supposed to set the
transfer size. Yet, the manual page says it sets the sector
size. Which isn't the same thing. A lot of conventional
disks support 512 byte sectors. A "512n" disk is native,
and externally visible and internal representation are
both the same. A 512n disk is "512,512".

A 512e disk (quite common in 2018), is 512 bytes externally
(emulated) for compatibility, while inside the drive, the
storage is done using 4096 sectors. This 512e disk
would be "512,4096". This is not a preferred option for
WinXP, but Vista+ OSes align on 1MB boundaries, so the
4096 sector size aligns with the 1MB boundaries. Most
cluster operations on Vista+ then align with the
internal representation, for maximum efficiency.

The third type is not common. A 4Kn disk is "4096,4096"
disk. There are few tools to use with it (partition management
is hopeless). Windows 10 I think, will support a 4K sector,
so Windows 10 could see one. But my recommendation to people,
is to stay far away from these, unless you want your
computer usage with them to be one continuous experiment
and breadcrumb exercise.

So the only part of my command that doesn't make a lot
of sense, is the -b8M. Does it set the maximum transfer
size ? Or does it set a sector size ? The program should
be able to read the information, just the same way that
fdisk does.

sudo fdisk /dev/sdb

If you select "p" for print, then "q" for quit,
there's a line near the beginning that shows the
512n, 512e, 4Kn nature of the drive. The internal and
external sector sizes are shown.

In any case, this is the syntax I'd be trying. The -b8M
may speed up the trial speed. The claim I read, is
the transfer size is "adaptive" and the command adjusts
the transfer size per command, to optimize bandwidth.
That's what the -b was supposed to do, according to the
documentation I was reading at one time.

ddrescue -b8M /dev/sda /dev/sdf ~/mymapfile.txt

Some more examples here.

https://unix.stackexchange.com/quest...-a-sparse-file

*******

You showed me a result before with HDTune, which is
consistent with your ddrescue result.

And both results make no sense :-/

There is something *weird* about that Mac disk.

An ATA disk will *not* be visible, if it has internal
troubles. The ATA disk spins up, and loads the heads onto
the platter, using a relatively small firmware loader
on the controller board.

The full ATA command set, is a larger chunk of code in
the Service Area of the platter. Otherwise known as
"Sector -1" because it is in an area that ordinary users
cannot access. Once the SA is loaded, the drive is ready
to accept ATA commands from the SATA bus.

The first command sent by the BIOS, is an "identify yourself".
And the returning of a single packet with "ST3500418..."
tells you that a SATA packet was eventually received
error free from the drive.

And we know enough of the drive works, that HDTune plays with
it in Windows.

But we also know, that an HDTune error scan, returns nothing
but red blocks. How is that possible ? How can the surface
be inaccessible like that, when we know the SA loaded
(a couple megabytes), and the drive came up ?

There is something about this disk, I just don't understand.

The only other breadcrumb I have for you, is certain
Macs years ago, needed the Spread Spectrum jumper
inserted on the back of the drive. Some brands of
drives have four pins. (Note that there can be *several*
four pin blocks, and you have to be careful to pick the
correct one.)

X X X X
Force150 SpreadSpectrum

The Force150 jumper is only needed for VIA chipsets
(something Apple isn't likely to use). The SpreadSpectrum
on the other hand, when you insert that jumper, it defeats
SpreadSpectrum clock modulation on the cable.

The purpose of SpreadSpectrum, is to defeat FCC15 testing.
It spreads the emissions to a slightly broader peak, so
hardware can pass FCC testing. It doesn't mean that the
device interferes any less with other radio equipment.

A very small number of interface chips, cannot track the
triangle wave modulation of SS. Normally, you'd use a PLL
or DLL or training clock, to come up with a scheme so you
can read packets while the clock rate continuously changes.
Some Apple chip could not do this at the time, and drives
connected to that Apple device, needed the SS jumper to
be inserted.

But other than that observation, I don't understand
how the entire surface of the disk is inaccessible,
while the SA reads fine and the drive comes up.
Would some service person have changed the jumper
state, and if so, why ?

Jumpers on those drives are probably 2mm type. There are
two jumper caps - 0.1" jumpers and 2mm jumpers, and one
type doesn't fit the other spacing all that well. I
had to look in my basement, in an old disk enclosure
product box, for a bag of ten 2mm jumpers I had. And
I've been using those over the years for stuff like
this.

I tried running the part number

ST3500418ASQ

only to find this gibberish about a "thermal sensor".

https://forums.macrumors.com/threads...cement.841205/

Some more here. These guys are usually pretty good at this
stuff (they tap into other forums to get the scoop
on "non-standard" crap).

https://blog.macsales.com/10206-furt...e-restrictions

Now, does that have anything electrically to do with the
drive ? Is it just the controller sensor, pinned out
to a header, so the controller can take external
temp readings ?

That should have nothing to do with reading data
from the drive. Whereas Spread Spectrum could.

I can't find that exact part number on the Seagate site.
It could be considered an OEM special just for Apple.

I haven't been able to find any dmesg Linux boot
cycles for that device, giving particulars. And the
Mac boot log is useless.

*******

Note the usage of branded firmware on the controller board. WTF?

http://firmware.hddsurgery.com/?manu...family=Pharaoh

ST3500418ASQ AP24 Pharaoh 5VM59RXH 2016-07-16

ST3500418AS CC37 Pharaoh 6VM66MWD 2016-07-16

The label on my 418AS drive shows it is running CC46, but
you can see the basic idea. That the "Apple OEM" drive
runs "APxx" firmware for some reason (maybe it does head park
or spins slower when idle or something, like a more aggressive
power management scheme).

So far, no evidence any of this affects reading data
from the drive.

I didn't rush this post off to you, because I suspect
we won't be getting any ddrescue data, until we figure
out what else isn't standard about the drive. I can't find
enough discussions in threads on the Internet about the
drive, to figure it out.

Perhaps you could take a picture of your hard drive or
at least examine it for differences to this.

https://s33.postimg.cc/6loshhxxb/ST3500418.gif

Even if the drive was encrypted, it should still read
without CRC errors. Why is the *whole* surface unreadable.
It's not a failure.

Paul

Boris wrote:
Paul wrote in news
Boris wrote:
Paul wrote in news
Boris wrote:
Paul wrote in newsj3h20$g9v$1@dont-
email.me:
Huge snip


Well, if you absolutely cannot get the table with smartctl
in Linux, go back to windows and use the Health tab
of HDTune 2.55.

http://www.hdtune.com/files/hdtune_255.exe

While Linux could be mis-interpreting some parameters
in SMART, it's possible the disk itself has some way
of indicating imminent failure after "doing the short
test" on its own. It could be a failure indicated by
short test, rather than an analysis of the SMART
parameter table to reach the same conclusion.

You really need to get working on your ddrescue/gddrescue.
And try and get as much data off the disk as possible.
Perhaps the active surface of the disk is toast, but
you'll discover that when you try. The thing is, the
disk would not have responded, unless the disk heads
loaded and the controller was able to read the
Service Area. So *some* portion of the platters
is readable. But we don't know how much.

Paul

I ran HDTune 2.55 a few weeks ago with the MAC HD USB tethered. The
results we

https://postimg.cc/gallery/25g6b1tdo/

The Health Tab displayed nothing for the MAC HD..

At the same time, to be sure HDTune was working correctly, I applied
HDTune 2.55 to my Windows OS disk, and it reported ok on all tabs but
the
Health Tab, which displayed nothing.

Yesterday, with the MAC HD connected directly to the SATA motherboard
connection, HDTune recognized all drives on my system, except for the
MAC
HD.

I'm not going to dick around any longer trying to get S.M.A.R.T.
dats.
I'm going to see what I can do with imaging the MAC HD to another
hard
drive.

It should have worked.

But ddrescue is where you have to go, and quickly.

The details don't matter any more, just the objective matters.
Save the sectors before it is too late.

Paul
So the next step was to try ddrescue. I remembered Frank Slootweg (in
this thread 7/6/2018) warning that:

"sda and sdb dependent on the sequence in which you connect the
original disk and the to-be-copied-to disk?"

I tested this, and discovered this is true, that the device designation
is
dependent on order of connection. With internal, USB flash, and USB
external drives attached, the sdX designations were different than if
only
the two disks I wanted to use were connected. Also, the designations
were
different depending on the order of connection. I guess Linux orders
them
in order of discovery.

I disconnected all disks (including the Win7 OS disk, not wanting to
blow
it up in error) and loaded up Knoppix. I then connected the MAC HD and
a
new Western Digital Passport 1TB HD.

MAC HD = sda (source, 500GB)
Passport HD = sdf (destination, 1TB)

Linusx Disks told me that the Passport drive was mounted at /media/sdf1

I tried to run ddrescue with a log file, but couldn't get the syntax
correct, or maybe I did, but here's the results:


knoppix@Microknoppix:~$ ddrescue -f /dev/sda /dev/sdf /media/sdf1
ddrescue: Mapfile exists and is not a regular file.
knoppix@Microknoppix:~$ ddrescue -f /dev/sda /dev/sdf
GNU ddrescue 1.22
ipos: 500107 MB, non-trimmed: 0 B, current rate: 0
B/s
opos: 500107 MB, non-scraped: 0 B, average rate: 0
B/s
non-tried: 0 B, bad-sector: 500107 MB, error rate: 17313
kB/s
rescued: 0 B, bad areas: 1, run time: 2h 55m
25s
pct rescued: 0.00%, read errors:984404307, remaining time:
n/a
time since last successful read:
n/a
Finished
knoppix@Microknoppix:~$


For the first few minutes, there was a line that said someting about
Trials 5. I thought this would last till the end of the run, but it
disappeared shortly, so I wasn't able to copy/paste it here.

I then logged on to the Passport drive...no changes.

Boris
The mapfile should be a text file, not a partition.

You transfer a whole-disk-identifier to a whole-disk-identifier,
to do device to device cloning. You got that part right.

/dev/sda /dev/sdf

The third item in the list, should be a text file. Perhaps that's
the map file they refer to.

All I have here at the moment to test with is:

KNOPPIX_V8.1-2017-09-05-EN.iso 4,553,826,304 bytes

Which one do you have ?

Exactly the same: Knoppix v8.1-2017-09-05, 4,553,826,304 bytes

This is where I found link to Knoppix, and the instructions on using this
particular live dvd:

https://www.data-medics.com/forum/ho...rive-with-bad-
sectors-using-ddrescue-t133.html

(I also have live dvd versions of Debianlive9.4.0 Cinnamon and Ubuntu-
18.04-desktop-amd64, which I've tried, but like Knoppix best.)

The package likely comes from Debian, and you could check
your version of ddrescue as well. Mine is "version 1.22
of GNU ddrescue".

ddrescue -V

I doubt it's highly sensitive to version, but I don't
want to wander too far off target.

Mine is also version 1.22, as shown on the copy/paste of the ddrescue
report.

And you have the basic form right, except the mapfile.

ddrescue -f /dev/sda /dev/sdf ~/mymapfile.txt

You can use "whoami" to check what account you
are using currently. On Knoppix, this is likely
"root", so sudo is not needed. On Ubuntu, you
would use...

I will have to check with "whoami" later, but I have been using sudo,
perhaps unnecessarily. I think I do remember that Knoppix logs me to
automatically right to the root.

sudo ddrescue -f /dev/sda /dev/sdf ~/mymapfile.txt

**********

ddrescue can copy from a device to a device, a device to an image file,
an image file to a device. In this example (one I tested), I transferred
a device to an image file.

sudo ddrescue -S -b8M /dev/sdb /mount/external/backup/sdb.raw
/mount/external/backup/sdb.log
The -S in that example, makes "sdb.raw" a "sparse" file, which
means that sectors full of zeros need not be recorded using
disk surface. Instead, a table of present or missing sectors
is kept, to conserve space. This only makes sense for disks
that are mostly full of zeros to start with. Normal disks
don't have an excess of sectors-full-of-zeros, so this -S
option will not help you.

The -b8M on the version I was using, was supposed to set the
transfer size. Yet, the manual page says it sets the sector
size. Which isn't the same thing. A lot of conventional
disks support 512 byte sectors. A "512n" disk is native,
and externally visible and internal representation are
both the same. A 512n disk is "512,512".

A 512e disk (quite common in 2018), is 512 bytes externally
(emulated) for compatibility, while inside the drive, the
storage is done using 4096 sectors. This 512e disk
would be "512,4096". This is not a preferred option for
WinXP, but Vista+ OSes align on 1MB boundaries, so the
4096 sector size aligns with the 1MB boundaries. Most
cluster operations on Vista+ then align with the
internal representation, for maximum efficiency.

The third type is not common. A 4Kn disk is "4096,4096"
disk. There are few tools to use with it (partition management
is hopeless). Windows 10 I think, will support a 4K sector,
so Windows 10 could see one. But my recommendation to people,
is to stay far away from these, unless you want your
computer usage with them to be one continuous experiment
and breadcrumb exercise.

So the only part of my command that doesn't make a lot
of sense, is the -b8M. Does it set the maximum transfer
size ? Or does it set a sector size ? The program should
be able to read the information, just the same way that
fdisk does.

sudo fdisk /dev/sdb

If you select "p" for print, then "q" for quit,
there's a line near the beginning that shows the
512n, 512e, 4Kn nature of the drive. The internal and
external sector sizes are shown.

In any case, this is the syntax I'd be trying. The -b8M
may speed up the trial speed. The claim I read, is
the transfer size is "adaptive" and the command adjusts
the transfer size per command, to optimize bandwidth.
That's what the -b was supposed to do, according to the
documentation I was reading at one time.

ddrescue -b8M /dev/sda /dev/sdf ~/mymapfile.txt

Some more examples here.

https://unix.stackexchange.com/quest...-partition-or-
hard-drive-to-a-sparse-file
*******

You showed me a result before with HDTune, which is
consistent with your ddrescue result.

And both results make no sense :-/

There is something *weird* about that Mac disk.

An ATA disk will *not* be visible, if it has internal
troubles. The ATA disk spins up, and loads the heads onto
the platter, using a relatively small firmware loader
on the controller board.

The full ATA command set, is a larger chunk of code in
the Service Area of the platter. Otherwise known as
"Sector -1" because it is in an area that ordinary users
cannot access. Once the SA is loaded, the drive is ready
to accept ATA commands from the SATA bus.

The first command sent by the BIOS, is an "identify yourself".
And the returning of a single packet with "ST3500418..."
tells you that a SATA packet was eventually received
error free from the drive.

I see. Didn't know that. So that's why you say something's weird.
And we know enough of the drive works, that HDTune plays with
it in Windows.

But we also know, that an HDTune error scan, returns nothing
but red blocks. How is that possible ? How can the surface
be inaccessible like that, when we know the SA loaded
(a couple megabytes), and the drive came up ?

So the SA area on the HD was supposedly scanned by HDTune, but returned as
a red block?

There is something about this disk, I just don't understand.

The only other breadcrumb I have for you, is certain
Macs years ago, needed the Spread Spectrum jumper
inserted on the back of the drive. Some brands of
drives have four pins. (Note that there can be *several*
four pin blocks, and you have to be careful to pick the
correct one.)

X X X X
Force150 SpreadSpectrum

The Force150 jumper is only needed for VIA chipsets
(something Apple isn't likely to use). The SpreadSpectrum
on the other hand, when you insert that jumper, it defeats
SpreadSpectrum clock modulation on the cable.

The purpose of SpreadSpectrum, is to defeat FCC15 testing.
It spreads the emissions to a slightly broader peak, so
hardware can pass FCC testing. It doesn't mean that the
device interferes any less with other radio equipment.

A very small number of interface chips, cannot track the
triangle wave modulation of SS. Normally, you'd use a PLL
or DLL or training clock, to come up with a scheme so you
can read packets while the clock rate continuously changes.
Some Apple chip could not do this at the time, and drives
connected to that Apple device, needed the SS jumper to
be inserted.

But other than that observation, I don't understand
how the entire surface of the disk is inaccessible,
while the SA reads fine and the drive comes up.
Would some service person have changed the jumper
state, and if so, why ?

Jumpers on those drives are probably 2mm type. There are
two jumper caps - 0.1" jumpers and 2mm jumpers, and one
type doesn't fit the other spacing all that well. I
had to look in my basement, in an old disk enclosure
product box, for a bag of ten 2mm jumpers I had. And
I've been using those over the years for stuff like
this.

I tried running the part number

ST3500418ASQ

only to find this gibberish about a "thermal sensor".

https://forums.macrumors.com/threads...cement.841205/

Some more here. These guys are usually pretty good at this
stuff (they tap into other forums to get the scoop
on "non-standard" crap).

https://blog.macsales.com/10206-furt...les-imac-2011-
model-hard-drive-restrictions
Now, does that have anything electrically to do with the
drive ? Is it just the controller sensor, pinned out
to a header, so the controller can take external
temp readings ?

That should have nothing to do with reading data
from the drive. Whereas Spread Spectrum could.

I can't find that exact part number on the Seagate site.
It could be considered an OEM special just for Apple.

I haven't been able to find any dmesg Linux boot
cycles for that device, giving particulars. And the
Mac boot log is useless.

*******

Note the usage of branded firmware on the controller board. WTF?

http://firmware.hddsurgery.com/?manu...family=Pharaoh

ST3500418ASQ AP24 Pharaoh 5VM59RXH 2016-07-16

ST3500418AS CC37 Pharaoh 6VM66MWD 2016-07-16

The label on my 418AS drive shows it is running CC46, but
you can see the basic idea. That the "Apple OEM" drive
runs "APxx" firmware for some reason (maybe it does head park
or spins slower when idle or something, like a more aggressive
power management scheme).

So far, no evidence any of this affects reading data
from the drive.

I didn't rush this post off to you, because I suspect
we won't be getting any ddrescue data, until we figure
out what else isn't standard about the drive. I can't find
enough discussions in threads on the Internet about the
drive, to figure it out.

Perhaps you could take a picture of your hard drive or
at least examine it for differences to this.

https://s33.postimg.cc/6loshhxxb/ST3500418.gif

Even if the drive was encrypted, it should still read
without CRC errors. Why is the *whole* surface unreadable.
It's not a failure.

Paul

Here's a pic of the drive and it's pins. The drive is an OEM made for
Apple, and there is a jumper block, but there is no jumper.

https://postimg.cc/gallery/3h3j12g8s/

I don't see any thermistor or connector with six pins (two
of which are wired) in the picture. But the drive is
running Apple firmware. Which might be nothing more
than aggressive spindown code (i.e. most of the ROM
is likely to be the same code as retail 418AS drives).

In the manual here for "Seatools For Windows", you could
try the "Short Drive Self Check". Don't use the "Fix All",
as that appears to be an attempt to get reallocations
going, and that's not going to work. You can get
"Seatools For Windows" from the Seagate site.

https://www.seagate.com/files/www-co...dows-en-us.pdf

If you press F8, apparently it offers the "Long Drive Self Check"
which is not in that picture. An older version of Seatools
(the one I have here), just put the short and long entries
in the menu, without needing to press a function key.

It's almost like your drive has had a data structure corruption.
The Service Area not only holds firmware which is loaded
into RAM, but it also holds data structures. Included
in those data structures, is the reallocation table.

But in the past, a typical situation is, when the data structure
thing is broken, the drive just "bricks". Normally, any
kind of problem with data structure, makes toast out
of the drive.

Other than that, I'm at a loss to explain how the
drive is able to read the Service Area, but cannot
read any other sector. It implies a firmware problem
of some sort. A Google search isn't picking up a
trend on that drive. There have been products
in the past, with a very strong theme, such as
failure exactly 30 days after the user bought
the drive.

The ATA standard allows downloading of drive firmware
into drive RAM (for usage during the current session).
A second command allows "committing" a firmware
download to the Service Area, making the firmware
permanent (equivalent to flashing). The drive
has a bootstrap routine stored in onboard flash.
The majority of the code (the part that parses ATA
commands and decides what to do), is stored in the
Service Area firmware store.

Your drive doesn't seem to have a hardware failure.
Something happens to it, after reading the Service
Area and it starts running the regular code to accept
input commands.

I'm hoping that when you run the SMART short test,
you'll get additional information. Since the main
code body is running at that time though, the SMART
might end up seeing all the CRC errors that the OS
sees.

Summary: Likely needs a Data Recovery company, unless
an identified issue with the drive is recorded
somewhere in Google. And I only see "normal"
failures for the drive at the moment. Mine,
for example, has a high reallocation count (400+).
Opening the HDA may not be necessary to fix
this, but blowing away the reallocation table
will "shred" the data (some files could end up
with sectors that don't belong there).

That drive model, varies from heaven to hell :-)
This is another one of my 418AS drives, which runs
continuously on this computer. This is probably the
second-longest-lived drive I've ever dealt with. The
record holder was 60,000 hours (a drive at work).
Considering the field statistics for this drive
model, how is this possible ???

https://s33.postimg.cc/mmiax893z/my_...t3500418as.gif

Paul

Boris wrote:

I finally got the command correct for Ubuntu v8.1-2017-09-05, running
ddrescue v1.22. It seems that Ubuntu will only write the mapfile (log) to
it's root, and it must be named 'mapfile', regardless of what the
instructions show. Here's what worked, and the results:

knoppix@Microknoppix:~$ sudo ddrescue -f /dev/sdb /dev/sdg mapfile
GNU ddrescue 1.22
ipos: 500107 MB, non-trimmed: 0 B, current rate: 0 B/s
opos: 500107 MB, non-scraped: 0 B, average rate: 55291 B/s
non-tried: 0 B, bad-sector: 499533 MB, error rate: 39174 kB/s
rescued: 574750 kB, bad areas: 1, run time: 2h 53m 14s
pct rescued: 0.11%, read errors:983272977, remaining time: n/a
time since last successful read: 2h 52m 45s
Finished
knoppix@Microknoppix:~$

Ironically, I forgot to record the mapfile. But, I'm not going to run the
scan again, at least not before posting this; it takes almost three hours
to run.

Naughty :-)

You *need* that mapfile, in case multiple runs are needed to
get more of the sectors. That's what the mapfile is for, to
maintain continuity from one run to the next. The mapfile is
updated on each run, with more good news.

Now, I was always pretty bad at maths. What exactly are
those results telling us ? That's yet another reason
why you need the mapfile, as it contains additional
information that can be compared to the above. Your
rescued data is 0.574GB if 500GB. You may have
spent 3 hours, but you got 0.11% of the data. That
means it will take 3000 hours to get the whole disk
back. I want the enormity of that to sink in. But maybe
I'm bad at maths.

The mapfile in such a case could be huge, if the recovered
data was a sector here and a sector there. It would chop
the disk up into many sections, which makes the mapfile larger.
If the condition of a bunch of sectors next to one
another is the same, the mapfile can contain a notation
that says how big the chunk is, whether it's good or
bad. The developers put some effort into making the
notation efficient.

At the current rate, it will take 3000 hours to complete.
But of course we know that's not true. Some portions of that
data is never coming back. And what is happening,
is you're spending 15 seconds on each unreadable
sector. (That's a typical timeout value, allowing
a ton of attempts to read the sector, by the
hard drive controller.) If you had a WDC RE Raid drive
with TLER (time limited error recovery), the timeout
is 5 to 7 seconds or so, somewhere in that ballpark.
(Only the RE drives have TLER.)

Now, back to work :-)

What you want to do it.

1) Do one run.
2) Take a snapshot of the amount recovered (0.11%
in this case), plus keep a copy of the mapfile for
reference.
3) Look up the manual page for how you're supposed
to run subsequent commands. You can try a reasonable
retry count, like one retry maybe, which changes the
time per sector from 15 seconds to 30 seconds.

ddrescue -r 1 -f /dev/sdb /dev/sdg mapfile

4) Do your second (-r 1) run. This will update the mapfile,
update the amount recovered.
5) If the trend looks good, if the second run with
a bit of a retry count recovered a lot more data
than the first run, you can then consider whether
to throw in the towel at that point, or continue
on. Each run allows you to refine your extrapolation
of the time to completion.

The fact 0.11% came back, also tells you that for some
reason, the surface is a mess. I was willing to accept
some kind of crazy firmware problem was causing 0%
to come back. But instead, it looks like a crazy
surface problem is allowing 0.11% to come back.

I *don't* understand why that disk isn't bricked!!!

How can that high a percentage of the drive be bad,
and the Service Area be intact ? It still makes no sense.

The manual page doesn't seem to define the terms it
uses (trimmed, scraped).

*******

The /dev/sdg drive should really be zeroed before
you begin. But since you've recovered so little
data on your first run, the following isn't
a priority.

In Windows (administrator command prompt), you'd
want to zero the /dev/sdg disk. You have to figure
out which Windows disk number that is, before
selecting a disk number.

diskpart
list disk
select disk 2
clean all
exit

In Linux, you could try this for your 500107862016
byte drive. The Block Size parameter should be
a multiple of 512 bytes, and 221184 is 432 sectors.

dd if=/dev/zero of=/dev/sdg bs=221184 count=2261049

I have a ST3500418AS running online on this machine,
which is why I can get the number. To get the
number for yourself, in Linux, you can use...

fdisk /dev/sdg
p
q

which should print the exact size of the disk in bytes.

If you weren't on Knoppix, you might need
"sudo fdisk /dev/sdg" as the command needs root
permissions.

Once the disk is zeroed, you can do your first ddrescue
run over again, and build a new mapfile.

You don't have to zero the output drive if you
don't want to. It's just easier later, if you're
using HxD hex editor and skimming through /dev/sdg,
you'll be able to see all those zeros where ddrescue
hasn't been able to read the source disk yet
and copy stuff over the zeros. The zeros are
a marker in a sense.

I think after two runs, you'll be in a good position
to give your 3000 hour runtime estimate to get the
whole thing :-/

I don't know what a data recovery company could do
for a disk like this. The heads seem to be intact.
The SA works. It's rotating. The heads load.
How can you fix the surface ??? Dunno.

Paul

Boris wrote:

I tried both SeaTools for Windows, and SeaTools for DOS. Both reported
failures.

SeaTools for Windows:
The Short Test keept failing at 14% to 21% while performing 'random reads'.

(I tested my Win7 OS drive just to be sure SeRTools was working, and the OS
disk passed all Short Test pricesses 100%).


SeaTools for DOS:
I burned an .iso and booted SeaTools for DOS. Here's the results (similar to
the Windows version):
https://imgur.com/a/yLHf0Ca

You can practice your ddrescue arts, now that
you have a worthy candidate in front of you.

We know it gets 0.11% of the drive on the first pass.

It would be interesting to run a second pass with
one retry (-r 1) and see what total percentage of the
drive is completed after that.

My guess is, you're not getting any files back.

If the 0.11% of the drive was contiguous sectors,
you could use Photorec or Recuva or scavengers
of that nature. You would want the /dev/sdg copy drive
to be zeroed out first, before ddrescue, if you
planned on running Photorec afterwards
against the copy of the drive. Photorec would scan
the 99.89% empty part of the sdg drive a lot
faster if the unrecovered sectors contain zeros. That's
one reason for cleaning /dev/sdg before using
it. Either diskpart in Windows and "clean all"
or dd from /dev/zero onto /dev/sdg in Linux
to clean it.

Say about 3 hours a step, 12 hours total.

dd if=/dev/zero of=/dev/sdg bs=221184 count=2261049
ddrescue -f /dev/sdb /dev/sdg mapfile
ddrescue -r 1 -f /dev/sdb /dev/sdg mapfile
photorec [on /dev/sdg]

Then review the results and see if you made
it to even 0.22% after the "-r 1" run.

You're practicing your arts, for the day that
you have a drive that's only missing a track or two...
You don't normally get drives this sick, to
practice on. I have *no* drives with the right
level of sickness here, to do ddrescue testing.
Any drive here that was sick, is dead now. That's
why your drive is so amazing. How can a 99.89%
dead drive still spin ?

Do you hear a lot of "clunking" or "clicking" come
from the drive during the ddrescue run ? This
would imply perhaps, loss of embedded servo.
Again, how can the servo wedges on each track
be working, when the data is so messed up ?
Bad controller board ? The servo wedges presumably
have enough info to tell the drive it's on the right
cylinder. If the platter surface was rusting,
it should take out the servo areas on each platter
too, and the drive should "click like crazy" because
it can't see where the heads have gone.

Paul