Spinrite

[Rod Speed]

The tech did set up the user's main apps to point
at the server, but the user began using other things.

Then he should have made them aware of that problem
if the desktop systems werent being fully backed up auto.

MS Office was factory installed, but the user probably never
mentioned needing it, so configuring it wasn't on the tech's mind.

He's obviously completely incompetant
and should be shown the door.

And there were other programs the user installed later.

He should have made them aware of that problem if
the desktop systems werent being fully backed up auto.

Why assume it didn't complain? It probably saw
this as a logical error and prompted the user for
permission to fix it, which the user granted.

Scandisk doesnt work like that.

So you would use only Scandisk?

I'd have full backups and if those werent available for
whatever reason and there was evidence of bads when the
hard drive manufacturer's diagnostic was run on the drive,
I certainly wouldnt be using scandisk to in that situation.

The only thing that makes any sense at all in that particular
situation is to clone the drive with a sector level cloner so
you can attempt the recovery of what data is recoverable
ON THE CLONE of the original drive and not risk buggering
up what data is available for recovery with crap like NDD.

I've seen cases where the opposite is
true, and only NDD could figure it out.

Of just that pair, sure. But there are much better utes around
than scandisk and NDD when a drive has developed bad sectors.

scandisk and ndd are only intended to cleanup logic errors
seen when a system hasnt been shutdown properly for
whatever reason and to do some basic checking of the
health of a drive when full backups are available.

After running Spinrite, niether NDD nor Scandisk could find a bad
sector on it. Therefor it would seem that Spinrite did something,

Or the drive's bad sector remapping did.

and this is not a bad electrical connection.

You dont know that either. Those can be surprisingly intermittent.

By 'specialize' I don't mean Scandisk should
not be able to even detect a physical problem.
I mean it's good the way it is, specializing in
logical errors as NDD and Scandisk do, but
with some capacity for detecting physical errors.
Sure.

Spinrite specializes in physical errors

Or claims it does, anyway.

and it's better that it doesn't do anything logical, because
logical errors can't be solved by looking at 1 sector at a time.

No reason why it cant do both.

The analysis has to take in the big picture, and
it's better to leave that to a different program.

Nope.

 

[Tom Del Rosso]

Then he should have made them aware of that problem
if the desktop systems werent being fully backed up auto.

He probably did make them aware, but users forget stuff like that. No
reason not to give him the benefit of the doubt.

Here's what kind of users we're talking about: A couple months ago the
boss was vacuuming around the server, and decided to vacuum out the dust
behind "those little doors" on the front of the server. After realizing
that he had pulled out a hard drive (RAID 1), he shoved it back in. The
machine started beeping (to signal that it was copying from the
remaining drive to the one just plugged in) so he thought it needed a
reboot. After rebooting it he called me up. I said, "STOP! I'll take
it from here." Fortunately the RAID controller completed the copy ok.

So I wouldn't assume it was the tech's fault for not explaining things.

The only thing that makes any sense at all in that particular
situation is to clone the drive with a sector level cloner so
you can attempt the recovery of what data is recoverable
ON THE CLONE of the original drive and not risk buggering
up what data is available for recovery with crap like NDD.

Since the subject is Spinrite I didn't bother mentioning it, but I did
both. I used Diskpatch to copy to a new drive, and that's the drive the
user is using now. Then I tested Spinrite on the old drive. The result
was about the same. Both had logical errors -- a little different but
the same severity. The end result is the same number of documents were
recovered both ways.

What I'd like to know now is, how good is Diskpatch at reading the
marginal sectors? Is anything better?

 

[Svend Olaf Mikkelsen]

Only if the sector is already a 'candidate bad sector' (has failed
to read within the retry limit). The process is designed to remap
sectors _before_ they become unrecoverably bad and reach that
candidate bad sector status. That happens when a sector is suc-
cessfully read by retries but crossed yet another limit doing that.

Reads fail because writes failed and a failed write is only de-
tected on a read. Drives do not normally write verify so can
not detect whether a write fails other than on the next read.
In that case the sector is marked as a candidate bad sector.

Are you certain? What about these words of wisdom from the Spinrite
site:

"The FIRST THING SpinRite does when it starts examining and working
with a drive is to completely disable the drive's built-in automatic
sector relocation. This way the drive can't whisk the sector away the
first time it's not easily read, and SpinRite can study the sector to
recover its data as much as necessary. (And as you might guess by now,
no other utility is even aware of this problem.) "

 

[Rod Speed]

He probably did make them aware,
but users forget stuff like that.

He clearly did a lousy job of making them aware of that then.

No reason not to give him the benefit of the doubt.

Every reason. It is stupid to just have proper backups of
the server in that particular situation and hope that the users
wont ever do something stupid on their desktop systems.

Here's what kind of users we're talking about: A couple months
ago the boss was vacuuming around the server, and decided to
vacuum out the dust behind "those little doors" on the front of the
server. After realizing that he had pulled out a hard drive (RAID 1),
he shoved it back in. The machine started beeping (to signal that
it was copying from the remaining drive to the one just plugged in)
so he thought it needed a reboot. After rebooting it he called me
up. I said, "STOP! I'll take it from here." Fortunately the RAID
controller completed the copy ok.

Thats what backups are for, so stupiditys like that are recoverable.

And that includes even more terminal stupiditys
like setting fire to the place and having it burn to the
ground by tossing a cigarette butt in the rubbish bin etc.

So I wouldn't assume it was the tech's fault for not explaining things.

Its clearly the tech's fault for not protecting rather
technically ignorant users against their inevitable stupiditys.

Since the subject is Spinrite I didn't bother mentioning it, but I did both.

Then there isnt any point in your comments about having the
utes do just one of physical and logical analysis of the drive.

I used Diskpatch to copy to a new drive, and that's the drive
the user is using now. Then I tested Spinrite on the old drive.
The result was about the same. Both had logical errors --
a little different but the same severity. The end result
is the same number of documents were recovered both ways.

So there wasnt any point in spinrite at all was there ?

What I'd like to know now is, how good is
Diskpatch at reading the marginal sectors?

Cant say I have ever tested it carefully.

Is anything better?

Dunno.

I go the other route, real backups.

 

[Folkert Rienstra]

The tech did set up the user's main apps to point at the server, but the
user began using other things. MS Office was factory installed, but the
user probably never mentioned needing it, so configuring it wasn't on
the tech's mind. And there were other programs the user installed later.

It can not notice a mismatch when it cannot read the sector
and doesn't yet know what's in it.

Why assume it didn't complain?

Because you didn't mention that it did, maybe?
Just a calculated guess, you being a responsible person?

It probably saw this as a logical error

It couldn't have.

and prompted the user for permis-
sion to fix it, which the user granted.

Notorious, eh?
It wasn't until Svend Olaf Mikkelsen happened to mention it.

So you would use only Scandisk? I've seen cases where
the opposite is true, and only NDD could figure it out.


Nope.


After running Spinrite, niether NDD nor Scandisk could
find a bad sector on it. Therefor it would seem that Spinrite
did something, and this is not a bad electrical connection.

That would be logical as well as physical ones.

It will have to in some cases and let the user decide how he
wants it handled.

By 'specialize' I don't mean Scandisk should not be able to even de-
tect a physical problem. I mean it's good the way it is, specializing in
logical errors as NDD and Scandisk do, but with some capacity for
detecting physical errors.

Spinrite specializes in physical errors and
it's better that it doesn't do anything logical, because logical errors
can't be solved by looking at 1 sector at a time. The analysis has to
take in the big picture, and it's better to leave that to a different
program.

Amen.

 

[Fred]

Reams of your puerile attempts at trolling flushed where they belong.

Notorious, eh?
It wasn't until Svend Olaf Mikkelsen happened to mention it.

More of your childish lying. Even you should be able to find my
comments on NDD long before Mikkelsen ever said anything.

 

[Svend Olaf Mikkelsen]

Certain on what?

Well. That I did not post that as an example of nonsense at the site.
And that I was not laughing.

As if diskdrives would just throw data away for fun.

This was necessary on some Quantums that used a similar modepage
scheme as SCSI drives through the "set configuration command".
They have a setting RUEE, Reallocate Uncorrectable Error Enables
which is set enabled. It reallocates bad sectors even when unreadable.

OK. I did not know that. Sounds unbelievable.

Any reputable diskdrive will not discard data by rigorously reallocating
bad sectors, (even) when they can't be read successfully.
There is little point in reallocating a sector when it is still considered bad
from a (user)data standpoint.
I thought we agreed on that.

We agree on that.

Still it is a fairly good guess that Spinrite did not recover one
single bad sector on a drive manufactured within the last 5 years, and
if a sector was partly recovered, the chance that the data would be
useful and needed is very small.

In cases where data from a bad sector is needed, the only reasonable
approach would be to copy data to another disk.

 

[Folkert Rienstra]

Certain on what?


What about them?

Or in other words, if you have point, please make it.

Well. That I did not post that as an example of nonsense at the site.

So why did you?

I couldn't find any problem to what I said and to what that para-
graph said except for *perhaps* the *suggestion* that drives
rigourously reassign bad sectors, even when not readable, where
as I *suggest* that that doesn't happen unless eventually read.
Maybe next time you better point out where you think the dif-
ference is instead of letting everyone guess what your point is?

And that I was not laughing.

It would actually have made more sense if you had, as it is kind of laughable.

OK. I did not know that. Sounds unbelievable.

Yes, doesn't it. Maybe the manual and the actual setting differ in real life.

We agree on that.

Still it is a fairly good guess that Spinrite did not recover one
single bad sector on a drive manufactured within the last 5 years,

Oh? Why not. What is your reason for saying that?

and if a sector was partly recovered, the chance that the data would be
useful and needed is very small.

You have no say over that.
SpinRite can do better than just reading a bad sector without ECC.
Although I will agree that the usefulness of partial data is probably limit-
ed to text and other 'original' data. It doesn't do any good for exact data
like executables but then these usually are not original (have backups of
sorts).

In cases where data from a bad sector is needed, the only reasonable
approach would be to copy data to another disk.

It's about time you gave a watertight explanation for that or stop spouting
that useless mantra.

 

[Folkert Rienstra]

[message references trimmed to get this to post]

[snip]

Since the subject is Spinrite I didn't bother mentioning it, but I did
both. I used Diskpatch to copy to a new drive, and that's the drive the
user is using now. Then I tested Spinrite on the old drive.
The result was about the same.
Both had logical errors -- a little different but the same severity.

Which makes it inconclusive to what SpinRite actually did.

The end result is the same number of documents were recovered both ways.

What I'd like to know now is, how good is Diskpatch at reading the
marginal sectors?

Not any better than anything else, if Joep is to believed. Marginal sectors
will read, that's why you call'm marginal. It's the unrecoverable read error
bad sectors that are the problem. I believe they just don't copy them.
That would be the equivalent of reassigning a bad sector without retrieving
the data. Converting the physical error into a logical one.

Is anything better?

They are researching the subject at the moment.

Btw, that is all in this thread.
Maybe if you focussed a little less on Roddles you might have noticed it.

 

[Svend Olaf Mikkelsen]

Oh? Why not. What is your reason for saying that?

That is my guess. To believe otherwise, I would need to see a
documented case. A more detailed description of the method than can be
guessed from the web site would not be enough.

 

[Folkert Rienstra]

That is my guess.

You can't just say "I don't believe it, therefor it doesn't happen".
Make a case, based on technical grounds.

To believe otherwise, I would need to see a documented case.

It's here, right under your nose.

 

[DIY DataRecovery]

[snipperdesnipsnip]

Cool.


Not any better than anything else, if Joep is to believed. Marginal sectors
will read, that's why you call'm marginal. It's the unrecoverable read error
bad sectors that are the problem.

Indeed, the can't be read, it's the nature of the problem.

I believe they just don't copy them.
Correct.

That would be the equivalent of reassigning a bad sector without retrieving
the data. Converting the physical error into a logical one.

Yep, contents of sectors that can not be read are replaced by a sector
filled with a 20h byte pattern (spaces). No retries are attempted as
in experience this is useles and only slows down the process.

They are researching the subject at the moment.

Who?

Btw, that is all in this thread.
Maybe if you focussed a little less on Roddles you might have noticed it.

Okay.

Joep

 

[Folkert Rienstra]

Didnt help, try again.

No, Freddles. Obviously a total waste of effort.

Didnt help, try again.
Nope.



Even you should be able to bullshit your way out
of your predicament better than that pathetic effort.

Presumably it was intended all along to be
just another of you peurile cryptic trolls that
was never meant to make any sense at all.

It's only you who doesn't understand, Rodney.
Oh and careful, Rodney, dont blow that vein.
That brainfart obviously just around the corner.

Obvious lie.

If you say so Freddles. Needless to say you can back that up.

Even you should be able to bullshit your way out
of your predicament better than that pathetic effort.

No need, Freddles.

Even you should be able to bullshit your way out
of your predicament better than that pathetic effort.

No need, Freddles.

Even you should be able to bullshit your way out
of your predicament better than that pathetic effort.

I never ever said anything even remotely resembling
anything like that, pathological lying child.

Obviously not, Rodney. Freddles did.

Another lie that anyone can check for themselves.

Nah, Freddles, they never do.

Even you should be able to bullshit your way out
of your predicament better than that pathetic effort.

Ditto, Freddles.

YOU made that terminally stupid claim, ****nert.

No Freddles, you did, as anyone can read in this thread.
You claimed it was pig ignorant. You back that up.

YOU get to do the backing up, ****nert.
THATS how it works, ****nert.

Clueless Freddles.

 

[Folkert Rienstra]

[snipperdesnipsnip]
Cool.

But not by Diskpatch.

Indeed, the can't be read, it's the nature of the problem.

Actually, they usually can but it's questionable what to do with it.

Yep, contents of sectors that can not be read are replaced by a sector
filled with a 20h byte pattern (spaces).

No retries are attempted as in experience
this is useless and only slows down the process.

There are other means like using specific read commands that even deliver data
when the result is error.

Who?

You're not? So your research is finished, then.

Given the somewhat odd response from Joep, what I meant is:
It has been mentioned all before, in this thread.

Okay.

't zal.

 

[Fred]

Some pathetic excuse for a troll claiming to be
Folkert Rienstra <[email protected]> mindlessly trolled in
message and fooled absolutely no one at all. As always.

Try harder, child. You might actually manage to fool someone, sometime.

 

[Joep]

But not by Diskpatch.
Huh?

Since the subject is Spinrite I didn't bother mentioning it, but I did
both. I used Diskpatch to copy to a new drive, and that's the drive the
user is using now. Then I tested Spinrite on the old drive.
The result was about the same.
Both had logical errors -- a little different but the same severity.

I read this like:

- Copied 'bad disk' 2 good disk using DiskPatch
- Fixed 'bad disk' with Spinrite

Both had logical errors -- a little different but the same severity. So
DiskPatch/Spinrite gave about equal results. Note that numerous disks were
recovered by simply copying them with DiskPatch accepting often just minor
logical damage.

There are other means like using specific read commands that even deliver data
when the result is error.

In my experience results are poor and it only takes time.

There are other means like using specific read commands that even deliver data
when the result is error.
idem

Well not you as you are busy trying and succeeding to be a smart ass.

You're not? So your research is finished, then.

If you're trying to be funny or sarcastic, it's a poor attempt. Even you
should be able to do better.

--
Joep

[snipperdesnipsnip]

The end result is the same number of documents were recovered both ways.

Cool.

But not by Diskpatch.

Indeed, the can't be read, it's the nature of the problem.

Actually, they usually can but it's questionable what to do with it.

Yep, contents of sectors that can not be read are replaced by a sector
filled with a 20h byte pattern (spaces).

No retries are attempted as in experience
this is useless and only slows down the process.

There are other means like using specific read commands that even deliver data
when the result is error.

Who?

You're not? So your research is finished, then.

Given the somewhat odd response from Joep, what I meant is:
It has been mentioned all before, in this thread.

it.

Okay.

't zal.

Joep

 

[Tom Del Rosso]

They are researching the subject at the moment.

Btw, that is all in this thread.
Maybe if you focussed a little less on Roddles you might have noticed

it.

Thanks, but I read everything and I didn't see it.

 

[Joep]

Hello,

Since the subject is Spinrite I didn't bother mentioning it, but I did
both. I used Diskpatch to copy to a new drive, and that's the drive the
user is using now. Then I tested Spinrite on the old drive.
The result was about the same.
Both had logical errors -- a little different but the same severity.

I read this like:

- Copied 'bad disk' 2 good disk using DiskPatch
- Fixed 'bad disk' with Spinrite

Both had logical errors -- a little different but the same severity. So
DiskPatch/Spinrite gave about equal results. Note that numerous disks were
recovered by simply copying them with DiskPatch accepting often just minor
logical damage.

Can you either confirm or deny this please?

Kind regards,

 

[Tom Del Rosso]

Hello,


I read this like:

- Copied 'bad disk' 2 good disk using DiskPatch
- Fixed 'bad disk' with Spinrite

Both had logical errors -- a little different but the same severity. So
DiskPatch/Spinrite gave about equal results. Note that numerous disks were
recovered by simply copying them with DiskPatch accepting often just minor
logical damage.

Can you either confirm or deny this please?

Yep, that's what I meant.

 

[Folkert Rienstra]

Yup.


I read this like:

- Copied 'bad disk' 2 good disk using DiskPatch

Right, DiskPatch had nothing to do with the repair, be that
the bad sectors on the original drive nor the logical errors
on the clone drive. It only copied the drive to another, strip-
ping possible data that may have helped in recovering the drive.

- Fixed 'bad disk' with Spinrite

Spinrite unmistakably did, but because of further logical
damage it is unclear how much it contributed positively to
the logical repair that was needed beyond that.

Based on my own experience of late I know that files can be
rescued even without FATs, and that based on that, FATs can
even be restored without ever cloning the drive to another one.
Svend's utilities are capable of restoring a drive without ever
cloning it. One of Svend's Fat repair utilities would have had
the same result as SpinRite by copying a good fat copy sector
over a bad one.

Cloning a drive has nothing to do with repair. A cloning utility
is the tool for those who totally mistrust what they are doing.

It would be the day that you had to buy another harddrive in
order to be able to run a defrag on it because it shouldn't be
trusted to do it's job properly and you had to clone it first.

Both had logical errors -- a little different but the same severity.
So DiskPatch/Spinrite gave about equal results.

Which should be read as "gave about equally _bad_ results", not
contributable to SpinRite nor DiskPatch. For a "good" result no
logical fixing should have been necessary in the case of SpinRite.
No hard conclusions can be made whether SpinRite didn't do any-
thing useful to the logical repair as neither did DiskPatch.

Note that numerous disks were recovered by simply copying
them with DiskPatch accepting often just minor logical damage.

And the same would have happened with IBMs DFT.
Or using Svend's Findbad.
Or using a diskeditor to write over the defective sectors.
Or let Scandisk sync the FATs as part of the repair.

Even doing totally nothing might result in that socalled "minor" damage.
Even repairing one file can make Scandisk sync the FATs and make all
FAT bad sectors disappear in one swoop. That same unexpected behaviour
may well have attributed to why additional logical repair was needed.

In my experience results are poor

and it only takes time.

No, it doesn't. Not in comparison with retries.
And time is what you have plenty of and is your friend if you want
as much as possible of your data back in as conveniant a manner.

Malloot.


Well not you as you are busy trying and succeeding to be a smart ass.


If you're trying to be funny or sarcastic, it's a poor attempt.

No, I was dead serious, based it on your own information even.

Even you should be able to do better.

Be careful of what you wish for.
Take a good look at yourself, Rodney van Steen.

Jij zou 's wat minder achterdochtig moeten zijn.
't Was bedoeld als een veer in je hoed. Als een aanmoediging voor
mensen die serieus bezig zijn met hun vak. Blijkelijk heb ik me zwaar
in je vergist. Wat is dat toch voor een kinderachtig debiel gedrag!
Als ik jou was zou ik 's even heel goed nadenken voor je op deze weg
doorgaat.

[snipperdesnipsnip]

The end result is the same number of documents were recovered both ways.


Cool.

But not by Diskpatch.

What I'd like to know now is, how good is Diskpatch at reading the
marginal sectors?

Not any better than anything else, if Joep is to believed. Marginal sectors
will read, that's why you call'm marginal. It's the unrecoverable read error
bad sectors that are the problem.

Indeed, the can't be read, it's the nature of the problem.

Actually, they usually can but it's questionable what to do with it.

I believe they just don't copy them.

Correct.

That would be the equivalent of reassigning a bad sector without retrieving
the data. Converting the physical error into a logical one.

Yep, contents of sectors that can not be read are replaced by a sector
filled with a 20h byte pattern (spaces).

No retries are attempted as in experience
this is useless and only slows down the process.

There are other means like using specific read commands that even deliver data
when the result is error.

Is anything better?

They are researching the subject at the moment.


Who?

You're not? So your research is finished, then.

Btw, that is all in this thread.

Given the somewhat odd response from Joep, what I meant is:
It has been mentioned all before, in this thread.

Maybe if you focussed a little less on Roddles you might have noticed it.

Okay.

't zal.

Joep