Spinrite analyzing hard drive slow

[Buck]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On the Spinrite page it says it performs hard drive analysis at 2GB's
a minute, so about an hour or more for a 125GB drive, but when I start
analyzing it goes extremely slow and says estimated time is 36 hours.
Why is it going so slow? My hard drive is not old, it is only about
1-2 years old, so I don't think it's the hard drive.

 

[Bob]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Mon, 27 Jun 2005 13:33:31 GMT, Buck <buck@tooth.com> wrote:

>On the Spinrite page it says it performs hard drive analysis at 2GB's
>a minute, so about an hour or more for a 125GB drive, but when I start
>analyzing it goes extremely slow and says estimated time is 36 hours.
>Why is it going so slow? My hard drive is not old, it is only about
>1-2 years old, so I don't think it's the hard drive.

The time for analysis depends on the bit pattern(s) used to perform
the tests. They range from very simple to very complex.


--

Map of the Vast Right Wing Conspiracy
http://home.houston.rr.com/rkba/vrwc.html

"The possession of arms is the distinction
between a free man and a slave."
-- Andrew Fletcher, Discourse on Government (1695)

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Bob" <spam@uce.gov> wrote in message news:42c007bf.91631765@news-server.houston.rr.com...
> On Mon, 27 Jun 2005 13:33:31 GMT, Buck <buck@tooth.com> wrote:
>
> >On the Spinrite page it says it performs hard drive analysis at 2GB's
> >a minute, so about an hour or more for a 125GB drive, but when I start
> >analyzing it goes extremely slow and says estimated time is 36 hours.
> >Why is it going so slow? My hard drive is not old, it is only about
> >1-2 years old, so I don't think it's the hard drive.
>
> The time for analysis depends on the bit pattern(s) used to perform
> the tests. They range from very simple to very complex.
>
Hillarious. Wotta Maroon.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Bob <spam@uce.gov> wrote in message
news:42c007bf.91631765@news-server.houston.rr.com...
> Buck <buck@tooth.com> wrote

>> On the Spinrite page it says it performs hard drive analysis at 2GB's
>> a minute, so about an hour or more for a 125GB drive, but when I start
>> analyzing it goes extremely slow and says estimated time is 36 hours.
>> Why is it going so slow? My hard drive is not old, it is only about
>> 1-2 years old, so I don't think it's the hard drive.

> The time for analysis depends on the bit pattern(s) used to
> perform the tests. They range from very simple to very complex.

That aint how spinrite works.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Rod Speed" <rod_speed@yahoo.com> wrote in message news:3ibbujFkg228U1@individual.net
> Bob <spam@uce.gov> wrote in message
> news:42c007bf.91631765@news-server.houston.rr.com...
> > Buck <buck@tooth.com> wrote
>
> > > On the Spinrite page it says it performs hard drive analysis at 2GB's
> > > a minute, so about an hour or more for a 125GB drive, but when I start
> > > analyzing it goes extremely slow and says estimated time is 36 hours.
> > > Why is it going so slow? My hard drive is not old, it is only about
> > > 1-2 years old, so I don't think it's the hard drive.
>
> > The time for analysis depends on the bit pattern(s) used to
> > perform the tests. They range from very simple to very complex.
>
> That aint how spinrite works.

Actually it does when it wants marginal sectors to go bad and replaced.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:42c08a9a$1$65640$892e7fe2@authen.white.readfreenews.net...
> "Rod Speed" <rod_speed@yahoo.com> wrote in message news:3ibbujFkg228U1@individual.net
> > Bob <spam@uce.gov> wrote in message
> > news:42c007bf.91631765@news-server.houston.rr.com...
> > > Buck <buck@tooth.com> wrote
> >
> > > > On the Spinrite page it says it performs hard drive analysis at 2GB's
> > > > a minute, so about an hour or more for a 125GB drive, but when I start
> > > > analyzing it goes extremely slow and says estimated time is 36 hours.
> > > > Why is it going so slow? My hard drive is not old, it is only about
> > > > 1-2 years old, so I don't think it's the hard drive.
> >
> > > The time for analysis depends on the bit pattern(s) used to
> > > perform the tests. They range from very simple to very complex.
> >
> > That aint how spinrite works.
>
> Actually it does when it wants marginal sectors to go bad and replaced.

Spinrite does not know what bits go to the head on modern drives.
Suggesting you can write complex vs simple bit patterns is nonsense.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Tue, 28 Jun 2005 11:41:23 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:

>There are 512x8=4096 bits in a sector.

Don't you mean 512 bits in a sector and 4096 bits in a modern, standard
NTFS cluster?

--
Michael Cecil
http://home.comcast.net/~macecil/
http://home.comcast.net/~safehex/

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Folkert Rienstra <see_reply-to@myweb.nl> wrote in message
news:42c08a9a$1$65640$892e7fe2@authen.white.readfreenews.net...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Bob <spam@uce.gov> wrote
>>> Buck <buck@tooth.com> wrote

>>>> On the Spinrite page it says it performs hard drive analysis at 2GB's
>>>> a minute, so about an hour or more for a 125GB drive, but when I start
>>>> analyzing it goes extremely slow and says estimated time is 36 hours.
>>>> Why is it going so slow? My hard drive is not old, it is only about
>>>> 1-2 years old, so I don't think it's the hard drive.

>>> The time for analysis depends on the bit pattern(s) used to
>>> perform the tests. They range from very simple to very complex.

>> That aint how spinrite works.

> Actually it does when it wants marginal sectors to go bad and replaced.

Nope.

 

[Bob]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Mon, 27 Jun 2005 14:43:14 -0700, "Eric Gisin"
<ericgisin@hotmail.com> wrote:

>> The time for analysis depends on the bit pattern(s) used to perform
>> the tests. They range from very simple to very complex.

>Hillarious. Wotta Maroon.

Troll Gisin shows off his profound ignorance once again.

Multiple test patterns are used to uncover possible signal aliasing.


--

Map of the Vast Right Wing Conspiracy
http://home.houston.rr.com/rkba/vrwc.html

"The possession of arms is the distinction
between a free man and a slave."
-- Andrew Fletcher, Discourse on Government (1695)

 

[Bob]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Tue, 28 Jun 2005 08:12:32 +1000, "Rod Speed" <rod_speed@yahoo.com>
wrote:

>> The time for analysis depends on the bit pattern(s) used to
>> perform the tests. They range from very simple to very complex.

>That aint how spinrite works.

Troll Rodboy checks in with his usual pontifications.

He doesn't know how testers work.


--

Map of the Vast Right Wing Conspiracy
http://home.houston.rr.com/rkba/vrwc.html

"The possession of arms is the distinction
between a free man and a slave."
-- Andrew Fletcher, Discourse on Government (1695)

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Bob <spam@uce.gov> wrote in message
news:42c148a7.5130218@news-server.houston.rr.com...
> Eric Gisin <ericgisin@hotmail.com> wrote

>>>> On the Spinrite page it says it performs hard drive analysis at
>>>> 2GB's a minute, so about an hour or more for a 125GB drive, but
>>>> when I start analyzing it goes extremely slow and says estimated
>>>> time is 36 hours. Why is it going so slow? My hard drive is not old,
>>>> it is only about 1-2 years old, so I don't think it's the hard drive.

>>> The time for analysis depends on the bit pattern(s) used to
>>> perform the tests. They range from very simple to very complex.

>> Hillarious. Wotta Maroon.

> Troll Gisin shows off his profound ignorance once again.

You do, as always.

> Multiple test patterns are used to uncover possible signal aliasing.

Pity Spinrite doesnt do it. Doesnt need to.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Rod Speed" <rod_speed@yahoo.com> wrote in message
news:3idic5Fkv98dU1@individual.net...
>
> Bob <spam@uce.gov> wrote in message
> > Multiple test patterns are used to uncover possible signal aliasing.
>
> Pity Spinrite doesnt do it. Doesnt need to.

What do you mean by 'doesn't need to'? That it's so ineffective, it doesn't
really need to do anything?

I gave it a shot on 2 drives. No effect at all. Just copying with
Diskpatch was the way to go, and less than half the price.


--

Reply in group, but if emailing add
2 more zeros and remove the obvious.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Tom Del Rosso" <ng01@att.net.invalid> wrote in message news:%Iiwe.367688$cg1.278086@bgtnsc04-news.ops.worldnet.att.net
> "Rod Speed" <rod_speed@yahoo.com> wrote in message
> news:3idic5Fkv98dU1@individual.net...
> >
> > Bob <spam@uce.gov> wrote in message
> > > Multiple test patterns are used to uncover possible signal aliasing.
> >
> > Pity Spinrite doesnt do it. Doesnt need to.
>
> What do you mean by 'doesn't need to'?

Just his usual bullshit.

> That it's so ineffective, it doesn't really need to do anything?

Like snake oil?

>
> I gave it a shot on 2 drives. No effect at all.

Depends on what effect you were looking for, getting rid of marginal
sectors or reading the contents of bad sectors and replacing them.

> Just copying with Diskpatch was the way to go,

Well Spinrite doesn't copy anything so obviously it couldn't do anything
in that department (except on a single sector basis within free space).

What were you trying to accomplish? Just copying with diskpatch didn't
get you more data than what you got from the original drive directly.

> and less than half the price.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:42c1dba0$0$86818$892e7fe2@authen.white.readfreenews.net...
>
> What were you trying to accomplish? Just copying with diskpatch didn't
> get you more data than what you got from the original drive directly.

Yes it did. Regular copy operations would fail on read errors in the FAT
(these were both from 98 PCs). I couldn't copy the files because they had
allocation errors, so after copying to a new drive with Diskpatch, Scandisk
was able to fix them.


--

Reply in group, but if emailing add
2 more zeros and remove the obvious.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Bob <spam@uce.gov> wrote in message
news:42c148f0.5203140@news-server.houston.rr.com...
> Rod Speed <rod_speed@yahoo.com> wrote

>>> The time for analysis depends on the bit pattern(s) used to
>>> perform the tests. They range from very simple to very complex.

>> That aint how spinrite works.

> Troll Rodboy checks in with his usual pontifications.

Blob make a spectacular fool of itself, yet again.

> He doesn't know how testers work.

I know how spinrite works thanks, arsehole.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Tom Del Rosso <ng01@att.net.invalid> wrote in message
news:%Iiwe.367688$cg1.278086@bgtnsc04-news.ops.worldnet.att.net...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Bob <spam@uce.gov> wrote in message

>>> Multiple test patterns are used to uncover possible signal aliasing.

>> Pity Spinrite doesnt do it. Doesnt need to.

> What do you mean by 'doesn't need to'?

There isnt any point in complex test pattern testing with hard drives.

> That it's so ineffective, it doesn't really need to do anything?

Nope, that the much more viable approach to working out the
weak spots with hard drives is to wind back the amplification
of the head amp. Thats what that liar Gibson claims spinrite
does. Its a lie. And the factory does that when working out
the weak bits of the media that go into the initial bads list.

The drive also monitors recoverable bads showing up later, and
adds them to the bads list and reallocates any that show up like that.

> I gave it a shot on 2 drives. No effect at all.

Yeah, Gibson has been lying about what spinrite can do for a long time now.

It can in theory get data when there is some other problem
with the drive other than the media going 'weak' which
doesnt happen in the field. Most obviously when there
is a crack in the flexible connection to the heads, repeated
retrys can see the data recovered just by using statistics.

> Just copying with Diskpatch was the
> way to go, and less than half the price.

Thats not necessarily always true with all drive failures tho.

I've never seen spinrite do anything useful, but then I'm not
stupid enough to do without backups of stuff that matters.

That may change, I've just replaced the VCRs with a digital
TV HTPC/PVR and the files are big enough to make full
backup not cheap, so I'll likely risk it with the less important
stuff and may want to try something like that if the main
capture drive fails. Or I might just cut to the chance and
have fully duplicated 250G drives anyway for the simplicity.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Rod Speed" <rod_speed@yahoo.com> wrote in message news:3idtq8Fkuqh2U1@individual.net
> Tom Del Rosso <ng01@att.net.invalid> wrote in message news:%Iiwe.367688$cg1.278086@bgtnsc04-news.ops.worldnet.att.net...
> > Rod Speed <rod_speed@yahoo.com> wrote
> > > Bob <spam@uce.gov> wrote in message
>
> > > > Multiple test patterns are used to uncover possible signal aliasing.
>
> > > Pity Spinrite doesnt do it. Doesnt need to.
>
> > What do you mean by 'doesn't need to'?
>
> There isnt any point in complex test pattern testing with hard drives.
>
> > That it's so ineffective, it doesn't really need to do anything?
>
> Nope, that the much more viable approach to working out the
> weak spots with hard drives is to wind back the amplification
> of the head amp. Thats what that liar Gibson claims spinrite
> does. Its a lie. And the factory does that when working out
> the weak bits of the media that go into the initial bads list.

Thanks for that obvious "Doesnt need to" bullshit.
Obviously is *does* need to as it can't do what you say Gibson
claims it does. Make up your mind Roddie. It's one or the other.

>
> The drive also monitors recoverable bads showing up later, and
> adds them to the bads list and reallocates any that show up like that.
>
> > I gave it a shot on 2 drives. No effect at all.
>
> Yeah, Gibson has been lying about what spinrite can do for a long time now.
>
> It can in theory get data when there is some other problem
> with the drive other than the media going 'weak' which
> doesnt happen in the field.

As if it happens anywhere else. Clueless.

> Most obviously when there
> is a crack in the flexible connection to the heads, repeated
> retrys can see the data recovered just by using statistics.

Huh?

>
> > Just copying with Diskpatch was the
> > way to go, and less than half the price.
>
> Thats not necessarily always true with all drive failures tho.
>
> I've never seen spinrite do anything useful, but then I'm not
> stupid enough to do without backups of stuff that matters.
>
> That may change, I've just replaced the VCRs with a digital
> TV HTPC/PVR and the files are big enough to make full
> backup not cheap, so I'll likely risk it with the less important
> stuff and may want to try something like that if the main
> capture drive fails. Or I might just cut to the chance and
> have fully duplicated 250G drives anyway for the simplicity.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Tom Del Rosso" <ng01@att.net.invalid> wrote in message news:TQlwe.368160$cg1.171714@bgtnsc04-news.ops.worldnet.att.net
> "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:42c1dba0$0$86818$892e7fe2@authen.white.readfreenews.net...
> >
> > What were you trying to accomplish? Just copying with diskpatch didn't
> > get you more data than what you got from the original drive directly.
>
> Yes it did. Regular copy operations would fail on read errors in the FAT
> (these were both from 98 PCs). I couldn't copy the files because they had
> allocation errors, so after copying to a new drive with Diskpatch, Scandisk
> was able to fix them.

Scandisk may have been able to fix them on the source drive too,
unless it times out before it's able to apply the fix.

You still haven't said what you were trying to accomplish with SpinRite
in this regard and how that failed. SpinRite has several types of run.

If Diskpatch was able to copy the data then that data must have been fixable by SpinRite too.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:42c259fb$0$76899$892e7fe2@authen.white.readfreenews.net...
>
> Scandisk may have been able to fix them on the source drive too,
> unless it times out before it's able to apply the fix.

If it would time out then what good is it?


> You still haven't said what you were trying to accomplish with SpinRite

Isn't it obvious? The drives were not readable, and I wanted to copy the
data.


> in this regard and how that failed. SpinRite has several types of run.

Error reported was in the FAT. Of course Scandisk ran automaticall when
they rebooted, as Win98 would always do, but it stopped when it couldn't
successfully write to the FAT.

Spinrite operated on the whole drives with all its tests, and it didn't make
the FAT any more readable than before. The first drive I worked on like
this showed improvement on the first attempt to read it, but that was
temporary, maybe due to a temperature change or something.


> If Diskpatch was able to copy the data then that data must have been
fixable by SpinRite too.

The data didn't need fixing -- the allocation tables did, but they weren't
readable.


--

Reply in group, but if emailing add
2 more zeros and remove the obvious.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Wed, 29 Jun 2005 10:55:17 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:

>If Diskpatch was able to copy the data then that data must have been fixable by SpinRite too.

Just because Diskpatch was able to complete it's run doesn't mean the data
was correctly copied, of course. And now that there are no errors on the
new disk, it will be more difficult to find those files with corrupt data.
This is about the same as when using the SnakeOil, er, SpinRite. Just
because it appears to fix the disk doesn't mean the data in the affected
files is correct.

Better to copy the good files and restore the rest from backups than
blindly assume the data is good.

--
Michael Cecil
http://home.comcast.net/~macecil/
http://home.comcast.net/~safehex/

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Michael Cecil" <macecil@comcast.net> wrote in message
news:f5o4c11ol72klo6ifrr3p7n13om693db69@4ax.com...
>
> Just because Diskpatch was able to complete it's run doesn't mean the data
> was correctly copied, of course. And now that there are no errors on the
> new disk, it will be more difficult to find those files with corrupt data.
> This is about the same as when using the SnakeOil, er, SpinRite. Just
> because it appears to fix the disk doesn't mean the data in the affected
> files is correct.

After the copy I ran Scandisk on the new drive, and it found allocation
errors in DLLs and such like, but not in any data files. All the bad
sectors had been in the beginning of the FAT where the Windows files were
allocated.

Anyway the point is that it was the best solution, and Spinrite did nothing.


> Better to copy the good files and restore the rest from backups than
> blindly assume the data is good.

Yeah, obviously, but just as obviously there was no backup or I wouldn't
have gone through that. The users' server was maintained by me, and backed
up nightly, but the users installed some apps on their own workstations and
didn't point those apps at the server, or tell me that they installed
anything, so there were no backups of the data they kept on the
workstations. Well, that was a few years ago, and now Win98 is gone and
they can't do that any more with only user rights.


--

Reply in group, but if emailing add
2 more zeros and remove the obvious.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Tom Del Rosso" <ng01@att.net.invalid> wrote in message news:28twe.12229$UG3.10262@fe11.lga
> "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:42c259fb$0$76899$892e7fe2@authen.white.readfreenews.net...
> >
> > Scandisk may have been able to fix them on the source drive too,
> > unless it times out before it's able to apply the fix.
>
> If it would time out then what good is it?

Then what good is what? Please be precise.
Are you referring to scandisk or SpinRite now?

>
> > You still haven't said what you were trying to accomplish with SpinRite
>
> Isn't it obvious?

No.

> The drives were not readable, and I wanted to copy the data.

I presume you wanted access to your data. That is something different.

>
> > in this regard and how that failed. SpinRite has several types of run.
>
> Error reported was in the FAT. Of course Scandisk ran automatically when
> they rebooted,

> as Win98 would always do,

No, you can disable that.

> but it stopped when it couldn't successfully write to the FAT.

Or refused to do that because it found a read error in same FAT.
I can't think of any reason for write errors anymore.

>
> Spinrite operated on the whole drives with all its tests, and it didn't make
> the FAT any more readable than before.

In that case, if a read error persists and it needs to go, in order to let
matters proceed, you want that sector overwritten. SpinRite can do that.

> The first drive I worked on like
> this showed improvement on the first attempt to read it, but that
> was temporary, maybe due to a temperature change or something.

Or the drive progressing further downhill.

>
> > If Diskpatch was able to copy the data then that data must have been fixable by SpinRite too.
>
> The data didn't need fixing --

In cloning everything is considered data. If the clone didn't need the data in the bad
FAT sector for scandisk to be able to successfully fix the filesystem errors then the
same could have been accomplished by letting SpinRite fix the bad sector in the FAT.
One possible exception might be that SpinRite, being aware of the filesystem, refuses
to do that though.

> the allocation tables did, but they weren't readable.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:42c32808$1$48021$892e7fe2@authen.white.readfreenews.net...
> "Tom Del Rosso" <ng01@att.net.invalid> wrote in message
news:28twe.12229$UG3.10262@fe11.lga
> > "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:42c259fb$0$76899$892e7fe2@authen.white.readfreenews.net...
> > >
> > > Scandisk may have been able to fix them on the source drive too,
> > > unless it times out before it's able to apply the fix.
> >
> > If it would time out then what good is it?
>
> Then what good is what? Please be precise.
> Are you referring to scandisk or SpinRite now?

Sorry, I refered to Spinrite because I thought you had. Reconsidering what
you wrote, I believe Scandisk did time out, so I don't see how it ever could
have fixed it.


> > The drives were not readable, and I wanted to copy the data.
>
> I presume you wanted access to your data. That is something different.

No, I certainly didn't want to access a drive that was dying.


> > Error reported was in the FAT. Of course Scandisk ran automatically
when
> > they rebooted, as Win98 would always do,
>
> No, you can disable that.

So what? It wasn't disabled and the point was that Scandisk ran and
indicated that the FAT was bad.


> > but it stopped when it couldn't successfully write to the FAT.
>
> Or refused to do that because it found a read error in same FAT.
> I can't think of any reason for write errors anymore.

Again so what? The disk was bad, Spinrite made no difference, and Diskpatch
copied all the data.


> > Spinrite operated on the whole drives with all its tests, and it didn't
make
> > the FAT any more readable than before.
>
> In that case, if a read error persists and it needs to go, in order to let
> matters proceed, you want that sector overwritten. SpinRite can do that.

Overwrite the bad sectors in the FAT? I don't see what good that would do,
but if Spinrite "could" have done something then I didn't prevent it. I had
it going with whatever the maximum test was.


> > > If Diskpatch was able to copy the data then that data must have been
fixable by SpinRite too.
> >
> > The data didn't need fixing --
>
> In cloning everything is considered data. If the clone didn't need the
data in the bad
> FAT sector for scandisk to be able to successfully fix the filesystem
errors then the
> same could have been accomplished by letting SpinRite fix the bad sector
in the FAT.

Do you think I didn't "let" Spinrite relocate it? It obviously couldn't do
it because the spare sectors were already used up, as they had to be for the
drive to show a bad sector in the first place.


> One possible exception might be that SpinRite, being aware of the
filesystem, refuses
> to do that though.

They claim Spinrite operates on the sector level, and I don't think they say
it can't relocate FAT sectors.


--

Reply in group, but if emailing add
2 more zeros and remove the obvious.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Michael Cecil" <macecil@comcast.net> wrote in message news:f5o4c11ol72klo6ifrr3p7n13om693db69@4ax.com
> On Wed, 29 Jun 2005 10:55:17 +0200, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
>
> > If Diskpatch was able to copy the data then that data must have been fixable by SpinRite too.
>
> Just because Diskpatch was able to complete it's run doesn't mean the data
> was correctly copied, of course. And now that there are no errors on the
> new disk, it will be more difficult to find those files with corrupt data.

> This is about the same as when using the Snake Oil, er, SpinRite.

No, it's not, unless you instruct it to always replace the sector, even
when the data couldn't eventually be read. Else the data is good.

> Just because it appears

There is no appearing, it does or it does not.

> to fix the disk doesn't mean the data in the affected files is correct.

But you would know, it would be by choice.

>
> Better to copy the good files and restore the rest from backups than
> blindly assume the data is good.