Path: utzoo!utgpu!water!watmath!clyde!att!alberta!calgary!maloff
From: maloff@calgary.UUCP (Sheldon Maloff)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Disk corrupt - task held
Keywords: guru to the maximum frustrastion
Message-ID: <1685@vaxb.calgary.UUCP>
Date: 17 Jun 88 23:41:47 GMT
References: <1657@vaxb.calgary.UUCP> <3932@cbmvax.UUCP> <1663@vaxb.calgary.UUCP> <552@sas.UUCP>
Distribution: na
Organization: U. of Calgary, Calgary, Ab.
Lines: 89

In article <552@sas.UUCP>, toebes@sas.UUCP (John Toebes) writes:
> In article <1663@vaxb.calgary.UUCP> maloff@calgary.UUCP (Sheldon Maloff) writes:
> >In article <3932@cbmvax.UUCP>, steveb@cbmvax.UUCP (Steve Beats) writes:
> >> In article <1657@vaxb.calgary.UUCP> maloff@calgary.UUCP (Sheldon Maloff) writes:
> >> >I've had this happen to me a few times now, and I'm beginning to get annoyed.
> >> >
> >> >	Disk Corrupt - Task Held
> >> >	Finish ALL Disk Activity
> >> >	etc.
> >> >
> >> >I go straight into a guru of this form
> >> >
> >> >	8700000B.265F48F1
> >> >
> >> >So I look up in my handy Amiga-Guru book on what this means and I find
> >> >out we have a fatal error in the dos library, specifically key out of range.
> >> >
> >> Exactly what do you do when the data coming off disk are bad ?
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> 	Steve
> >
> >How difficult could this be?  I mean specifically key out of range.  When
> >this happened to me almost always the disk window pops up and then I get the
>
> One of the best suggestions I can make about being able to discuss this issue
> is to attempt to write a file system.  I have spent the past months working

Uh Uh, can't do.  Have to much time devoted to my job.  I'll have to let the pro's
of the Amiga deal with this.

> Because of the structure of the file system (which incidently is quite sound)

No doubt here.  I beleive it just by running disksalv on a trashed disk.
Recovery of nearly every file.

>   1) Reading a file - simple just return an I/O error to the program attempting
>      to do the read and fire up the validator (again).

Fire up the validator.  And if it can't do anything with the disk, give me a
requester saying the disk is bad.  Let me take it out of the drive, and I'll
fix it at a later date, but don't GURU on me.

>   2) Writing a file - this is an absolute disaster since the handler just
>      created all the keys.  This DOES OCCUR if you pop a diskette while
>      writing.  The file system attempts to handle this with the 'You MUST...'

I'm not worried about popping a disk.  That YOU MUST... requester is good, and I've
seen it a few times, but usually only while I popped the disk when there was a
pause in the write, and I thought it was done.  I've never trashed a disk this way.
I HAVE trashed when I popped while a write was in progress, but again, a good
requester like "you fool! you just made me trash a disk."  Abort the write, let
me pop it in again and try to read it.  Now were back at case 1.  No GURU's!

>   3) Searching a directory - If the key is out of range then there is reasonable
>      doubt that this is even a directory block (or at lease a valid one).

Give me a requester saying "Possibly not a directory, can't properly read disk,
use disksalv".  Don't GURU.

> As you can see, there is a central theme to this solution.  You must be able
> to refire the validator (intelligently) and respect what it says.  But what
> do you do if you were writing a file and the validator decided the disk was
> bogus?  This is a last ditch situation already, oh, I know, let's fire off the
> validator to clean it up.. (oh, we just did that).  I too long for a good

Fire the validator once.  Respect what it says.  After that, let me get the damn
disk out of my drive.  The system does not have to lose its sanity because
of *my*, *a user*, error.  A good informational requester.  I'll fix the disk on
my own time, when I don't have 5 or 6 other *important tasks* running.

> Please, take the time to research the issues first.  There is no substitute to
> understanding the subject before 'batting around a few ideas'.  There are a

I program for a living.  I research issues, for *my job*.  At home I'm a
USER.  A plain joe with a computer.  It is not the responsiblity of the
USER to research things looked at by programmers, and tossed off as,
"...Boy I Can't deal with that, I'll just guru."  You've noticed the error,
state it, get the disk out of the drive, and live on.  Provide a good
disksalv utility as standard.  Give it good documentation, so that the
average joe can, when he wants to sacrifice his system to insanity, try and
recover the disk.

>  |_o_o|\\   John A. Toebes, VIII       usenet:..mcnc!rti!sas!toebes

|| Sheldon                               ----========== \\        -----======||
|| maloff@calgary.UUCP                      -----====== //  Calgary, Alberta ||
|| {ihnp4!alberta}!calgary!maloff               -----== \\  Past Host of the ||
|| .. eventually, we'll all be scaled by zero and  ---= //  '88 Winter Games ||
|| converge upon the origin ... then we'll party!    -= \\              ---==||