Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!umd5!uvaarpa!mcnc!rti!sas!toebes
From: toebes@sas.UUCP (John Toebes)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Disk corrupt - task held
Keywords: guru to the maximum frustrastion
Message-ID: <552@sas.UUCP>
Date: 13 Jun 88 13:53:30 GMT
References: <1657@vaxb.calgary.UUCP> <3932@cbmvax.UUCP> <1663@vaxb.calgary.UUCP>
Reply-To: toebes@sas.UUCP (John Toebes)
Distribution: na
Organization: SAS Institute Inc, Cary NC
Lines: 86

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
>requester.  If a key is out of range couldn't you simply ABORT whatever you
>are doing.
>
>My problem is I consider a disk and file system sacred.  If there is an
>error in the system every possible chance should be given to recovery
>of the system sanity.  If the problem can be trapped, then catch it and 
>deal with it.  Granted there is eventually somepoint where recovery
>cannot be made, guru then and only then.  But don't simply say, "oopsy,
>troubled waters, GURU!"
>
>I'm somewhat curious (comes from being naive about the Amiga file system)
>just what all the problems are.  Why don't we toss
>some of them back and forth over the net and get the problem fixed right
>for a future release?  Why don't we start with some of the problems of
>key out of range?
>
>Looking forward to a good discussion.

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
on a file handler that is 1.2 compatible (currently working).  it is amazing
how many of the same problems I have run into as exist in the current handler.
There is really only one OBVIOUS intelligent way to write the code.

Because of the structure of the file system (which incidently is quite sound)
you are dependent upon keys to get you from one place to another.  If
a particular key is out of range, what do you do?  Let us look at the
situations that immediately come to mind:
  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).
  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...'
     requester, but it is no guarentee.  Think about how you would have to
     program if at any time a variable you just set were changed without
     you getting notification...  Of course we could solve this by revalidating
     the entire disk every time you pop it.  There are implications about open
     files that you REALLY DON'T want to get into now.  Trust me.
  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).
     In all likely hood, attempting to continue will result in quite a
     disaster of infinite looping through the disk trying to walk the
     directory.  Of course you could revalidate the disk but what if you were
     in the middle of a RENAME operation?

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
solution and am working hard to find reasonable ones, but the only way to
do it is with experimentation and truely understanding all the situations.

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
lot of theoretical approaches to the problem but few will have real
applicability to the problem.  There are just too many factors involved.

 |_o_o|\\   John A. Toebes, VIII       usenet:..mcnc!rti!sas!toebes
 |. o.| ||
 | .  | ||  Coordinator of ...
 | o  | ||    The Software Distillery
 |  . |//     USnail: 235 Trillingham Ln, Cary NC 27513
 ======       BBS: (919)-471-6436