fsck on FAT32 filesystem?

[Jerry]

On Mon, 16 Jul 2012 09:04:31 -0500 (CDT)
Robert Bonomi articulated:

> > From owner-freebsd-questions at freebsd.org  Sun Jul 15 16:31:45 2012
> > Date: Sun, 15 Jul 2012 23:29:39 +0200 (CEST)
> > From: Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl>
> > To: FreeBSD <freebsd-questions at freebsd.org>
> > Subject: Re: fsck on FAT32 filesystem?
> >
> > > totally in error. SpinRite will attempt to read a damage sector
> > > up to 2000 times and through different algorithms determine what
> > > is most
> >
> > man dd
> >
> > conv=sync,noerror
> 
> 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.

-- 
Jerry ♔

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________