RE: [SLUG] hd recovery

From: Ken Elliott (kelliott11@cfl.rr.com)
Date: Sat Jan 20 2007 - 00:06:56 EST


>> For my sister's iBook, actually. She dropped it and killed the hard
drive.

My tool of choice for HDD repair.

http://www.grc.com/sr/spinrite.htm

Ken Elliott

=====================
-----Original Message-----
From: slug@nks.net [mailto:slug@nks.net] On Behalf Of Eben King
Sent: Friday, January 19, 2007 8:32 PM
To: SLUG Mailing List
Subject: [SLUG] hd recovery

For my sister's iBook, actually. She dropped it and killed the hard drive.
Bad sister. So I've got a "Mounting Kit for 2.5" IDE hard drive in 3.5"
bay", and it's copying as I type. It's going at, on average, 17.x K/s.
Slon. This is due to the extremely high number of errors (some 18000 in the
first 2.6 GB). I can only hope that this is where most of the errors are
concentrated, otherwise this will take all month, literally: 40E9 B/(17825
B/s) ~= 2.2E6 s ~= 26 days.

It's retrying some block 81 times, until it gives up and gives dd a read
failure. I note that 81 = 3^4, so I presume that (instead of it being an
arbitrary number) four nested loops each calls its subsystem three times.
BICBW.

She said that all she would like to see from this drive is any JPEG images
and MP3 music. Fine. So I've got a process running (it does maybe 30
blocks/sec):

    ,--
  1 | #! /bin/bash
  2 |
  3 | [ $# = 2 ] || { echo "Usage: $0 limit_low limit_high" ; exit 1 ; }
  4 |
  5 | limit_low=$1
  6 | limit_high=$2
  7 |
  8 | block=$limit_low
  9 | while [ c$(dc -e "[[ontinue]p] sA $block $limit_high >A") = continue ]
; do
10 | echo "$block " >&2
11 | result=$(dd if=/mnt/temp/lis-hd.img bs=512 skip=$block count=2048
2> /dev/null | file -)
12 | [ "$result" = "/dev/stdin: data" ] || echo "$block
${result#/dev/stdin: }"
13 | block=$(dc -e "$block 1 + p")
14 | done
    '--

I started off using `seq A B` to generate the block numbers, but something
froze up at between 50K and 100K of them. Then I found that for numbers
past a million, something uses scientific notation. No good. So I switched
to this, which works.

That listing looks like this:

1906747 DBase 3 data file (956307456 records)
1906752 binary Computer Graphics Metafile
1906755 RISC OS archive (spark format)
1906768 DBase 3 data file (15420146 records)
1906771 MPEG sequence
1906791 shell archive or script for antique kernel text
1906797 binary Computer Graphics Metafile
1906799 Assembler source
1906801 DBase 3 data file (555032853 records)
1906802 shell archive or script for antique kernel text
1906821 DBase 3 data file (184551168 records) 1906840 DBase 3 data file
1906843 DBase 3 data file (738207232 records)

One of these days I'll get bugged enough to fix the spelling of "sparc".
Heck, it's an acronym for "Scalable Processor Architecture" so it oughta be
capitalized, right?

Just for reference, an actual JPEG on my system looks like this:

/export/media/backgrounds/acropolis.jpg: JPEG image data, JFIF standard 1.01

So I grep 'JFIF' from that mess of block IDs, and use "dd" to extract it
from the hard drive image, assuming that almost all JPEGs are less than 1
MB. (Good assumption?) I can trim the file losslessly by using "jpegtran"
to rotate it 180 degrees, then do it again. How can I verify that it is, in
fact, a valid image file? "file" isn't always right. In fact, I really
doubt that there is a "RISC OS archive" and a "Computer Graphics Metafile"
on there.

There are a fair number of offsets that yield the same image. Since I don't
have the names anyhow, I guess I'll store them by the md5sum, to weed out
duplicates. Naturally I'll do this all programmatically.

How do I do a similar trimming and verification for MP3s? Lossless, if
possible.

-- 
-eben   QebWenE01R@vTerYizUonI.nOetP   http://royalty.no-ip.org:81

Every normal man must be tempted at times to spit upon his hands, hoist the black flag, and begin slitting throats. -- H.L. Mencken ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.

----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:42:00 EDT