fsck on FAT32 filesystem?

[Adam Vande More]

On Mon, Jul 16, 2012 at 10:50 AM, Jerry <jerry at seibercom.net> wrote:
>
> >
> > This is *precisely*  why dd is _grossly_inferior_ to
> > professional-grade tools like Spinrite.
> >
> > With the settings the resident "infallible expert on everything"
> > <*SNORT*> recommends, dd will make _one_ attempt to read each disk
> > sector, going through the O/S's device driver code, and write out
> > 'whatever it got', regardless of whether or not ane sort of
> > read-error was signalled.  This results in GUARANNTEED,
> > *UNRECOVERABLE*, GARBAGE in the copy, _every_ place where a read
> > error was encountered.  This result can be marginally acceptable --
> > for 'first-cut' attempts at accessing 'easily recoverable' data on
> > the disk.
> >
> > 'dd' is purely 'amateurville', however, when it comes to recovering
> > =critical= data inside an 'unreadable' (by the O/S) disk block.
> >
> >
> > Spinrite, and other professional-grade tools, run absolutely
> > stand-alone, without the use of _any_ O/S drivers, or even BIOS
> > code.  Spinrite _directly_ programs the hard-disk-controller chip,
> > can retrieve into memory _every_ bit -- including address-marks,
> > sector framing, recorded ECC bits, and so on -- on a track, for
> > analysis, can seek from an inner track, read the bits, then seek from
> > an _outer_ track, and do another read. It can also do things like
> > step the heads 'fractionally' off the track center, and read
> > _there_.  By doing these kinds of *very*low*level* operations, that
> > are forbidden to any 'userland' task, by an O/S, tools like Spinrite
> > can do a FAR BETTER job of extracting data from damaged disks.
> >
> > Professional-grade tools can also do things like 'pre-initialize' the
> > I/O buffer _in_the_disk_itself_, with _different_ bit patterns on
> > multiple read passes,  They can thus find bitstrings that are (a) the
> > 'prior data' in th buffer, (b) bits that are read consistently from
> > the disk, and (c) bits that 'change value' from one read attempt to
> > the next.  This allows such tools to do a much better job of
> > RECONSTRUCTING the actual data in the 'error' sector(s).
> >
> >
> > "Make a copy, and work only on the copy" _is_ good advice for
> > attempting 'simple' data recovery with tools that run in 'userland',
> > under an O/S. When the 'simple' approach fails, or is insufficient,
> > it is time to bring out the "big guns" -- things like Spinrite --
> > which -require- direct accesss to the original damaged disk. Since
> > Spinrite, and similar tools, operate READ-ONLY on the disk -- which
> > is *not* guaranteed if there is a general-purpose O/S in the wa -- it
> > _is_ generally safe to let them access the damaged original.  The
> > problematic situation is where spinning up the drive causes -more-
> > damage to the media..
>
> +1
>
> I use to keep SpinRite on a flash drive that I could easily carry with
> me if needed. Of course that would require the machine to be worked on
> to have the ability to boot from a flash drive. Unfortunately, not all
> of them could. Fortunately, I almost never need an industrial strength
> recovery product like SpinRite. It is nice to know it is available if I
> do though.


SpinWrong is a scam, Gibson is a fraud, and this conversation is pure
marketing gibberish. I thought most had overcome this credulity years ago.
 It appears I was mistaken.


-- 
Adam Vande More