[comp.sys.amiga] DH0: Disk Validation Error

Gregs@alake.FIDONET.ORG (greg sheppard) (03/15/90)

  Recently, I modified my Startup-SYS file with a shareware "vi" editor.
The next thing I know, I'm getting a "disk not validated" error when
trying to write to DH0:.  I can't rename, copy or write to DH0: in any
fashion.  I'm at a loss as to what is causing this.  The only thing I
can think of is that I wrote the file back as "startup-sys" and maybe
the system can't find it??  Is it necessary to re-format the hard-drive
at this point...is there some less drastic technique which will get me
my disk back?


--- msged 1.99S ZTC
 * Origin: 'The Beat BBS 206-581-7966 [Fido & Usenet...nwnexus!alake]' (1:138/117)
--  
Greg Sheppard                                   Telephone: 1-206-581-4276
imop@alake.UUCP                                      Work: 1-206-581-8924

rrmorris@uokmax.uucp (Rodney Raymond Morrison) (03/18/90)

In article Gregs@alake.FIDONET.ORG (greg sheppard) writes:
>
>  Recently, I modified my Startup-SYS file with a shareware "vi" editor.
>The next thing I know, I'm getting a "disk not validated" error when
>trying to write to DH0:.  I can't rename, copy or write to DH0: in any
>fashion.  I'm at a loss as to what is causing this.  The only thing I
>can think of is that I wrote the file back as "startup-sys" and maybe
>the system can't find it??  Is it necessary to re-format the hard-drive
>at this point...is there some less drastic technique which will get me
>my disk back?

Something bad happened during a write to your HD. Your HD's bitmap has benn
all messed up. Run info and you will see that it says there is 0% space
left on your HD (bad bitmap). I had to reformat when this happened to me.
If anyone knows of a utility or how to rebuild Amigados file system bitmaps,
please leave a message as I also would like to know how to coorect this if
it ever happens again.

bdb@cl.cam.ac.uk (Brian Brunswick) (03/18/90)

In article <1990Mar17.225353.24099@uokmax.uucp> rrmorris@uokmax.uucp (Rodney Raymond Morrison) writes:
>In article Gregs@alake.FIDONET.ORG (greg sheppard) writes:
>>  Recently, ...
  Tale of misfortune
>> Is it necessary to re-format the hard-drive
>>at this point...is there some less drastic technique which will get me
>>my disk back?
>
   
>... I had to reformat when this happened to me.
>If anyone knows of a utility or how to rebuild Amigados file system bitmaps,
>please leave a message as I also would like to know how to coorect this if
>it ever happens again.

I have several times had nasty things happen to my hard disk, but a bit of
delicate work with a disk editor has always managed to resurrect it.
I know this may sound daunting, but its not really that hard.

First of all, you need a copy of the amigados manual for the disk layout,
and a disk editor which can correct the block checksum - though I still go
through the tortuous route of two little utilities I wrote which write/grab
physical bits of a disk to/from a file, and write the sector onto a floppy
to use an ancient version of disked to fix it.

Anyway, when an amigados disk is mounted, it looks at word #78 of the root
sector, (which is the precise middle of the disk - when calculating
remember that highcyl is inclusive) to see if it is -1 or 0, meaning
there is a bitmap on the disk or not. If not, it will try to rebuild
the bitmap (5 mins of disk fiddling), using I think L:disk-validator if it can
find it. First attempt to fix a disk - zero this word, rewrite block with
correct checksum, and do a diskchange or other prod to try mounting.
If the validation fails at some particular key (ie. sector), you will
need to go down into the directory structure, and change it to remove whatever
is causing validation to die. This structure is explained roughly in the
amigados manual, and the directory part appears to be the same for FFS as
for old file system. Each directory sector contains a table of heads
of linked lists of files and directories which hash onto the same value.
Use disked or some such on a file name to get it to tell you which word's
list the name will have hashed into, and follow the tree down.
list dirname keys will also tell you the sector that a file header is at.
When just above the dying bit, zero the word to chop off all the files etc that
were attached - or more ambitiously, just unlink one from the list.
Then try another validate attempt.

The only thing that may be irritating is trying to find out in which file
a doubly used block is - this could be done on the old fs by following
back pointers - now, I don't know.

Brian Brunswick, bdb@uk.ac.cam.cl, bdb10@uk.ac.cam.phx. Short .sig rules!

chymes@fribourg.csmil.umich.edu (Charles Hymes) (03/20/90)

> This structure is explained roughly in the amigados manual, and the directory
> part appears to be the same for FFS as for old file system. Each directory 
>sector contains a table of heads of linked lists of files and directories which
> hash onto the same value.

I dont think this is true. If it is, then DiskX, Sectorama,DiskED and a couple 
more of the like all have bugs when they try to edit FFS disks. In my excuresions
through disk hell, I have found no decent aid. All the disk editors I have found
only work reliably with Old_Dos disks, yet my FFS partition is the only one that
gets corrupted. And it gets currepted regularly. I am going to write a disk editor
that works correctly with FFS partitons, but as yet CATS has not send me the 
AmigaMail binder, the ONLY official place where the info on FFS is kept.
When I posted a plea on this same topic a couple of months ago, I was given two
kinds of advice, A, edit the sectors, which wouldnt work because of the FFS, and
B, save what I could and reformat. I'm still looking for an alternative to B,
but as yet I havent found one.

Charlweed Hymerfan, Intrepid explorer of Disk Hell

bdb@cl.cam.ac.uk (Brian Brunswick) (03/20/90)

In article <1990Mar19.161933.20452@csmil.umich.edu> chymes@fribourg.csmil.umich.edu (Charles Hymes) writes:
>
>> This structure is explained roughly in the amigados manual, and the directory
>> part appears to be the same for FFS as for old file system. Each directory 
>>sector contains a table of heads of linked lists of files and directories which
>> hash onto the same value.
>
>I dont think this is true. If it is, then DiskX, Sectorama,DiskED and a couple 
>more of the like all have bugs when they try to edit FFS disks. In my excuresions
   ....
>Charlweed Hymerfan, Intrepid explorer of Disk Hell
Hmm.. perhaps I have gained from not using the editors to do anything except
calculate checksums then. The data part is certainly different - it appears to
be just contiguous data - but I have successfully edited a ffs volume several
times working from guesses and the 1.1 AmigaDOS manual, so don't despair.
Perhaps you need as simple minded a program as possible, eg disked.
Stay clear of the files, and just change directories, and you may be ok.
Of course, it all depends on whether validation fails in a well defined place..
Still.. good luck.


Brian Brunswick, bdb@uk.ac.cam.cl, bdb10@uk.ac.cam.phx. Short .sig rules!

akcs.clemon@wcbcs (Craig Lemon) (03/21/90)

>>the system can't find it??  Is it necessary to re-format the hard-drive
>>at this point...is there some less drastic technique which will get me
>>my disk back?

Have you tried the PD program FixDisk?  It can be used as a last resort by
typing 
'fixdisk doom'.  This sets is into an untested mode where it works on HDs. 
I used it on an FFS floppy that was totally destroyed "Non-DOS Disk" style
just to see what it would do.  It found ALL of the files and repaired the
bad block (The ROOT block) with an interesting algorithm to try to decode
the poor block.  After a "WRITE?  yes/no" requestor it corrected the disk. 
No Problems.  The program is quite intuition based and looks much like a
file requestor with several permitted operations on files, tracks or the
entire disk.  Might be worth looking into.

--                            _
 Craig Lemon              // |_|               
 Kitchener, Ontario     \X/  | |  M  I  G  A   
                                               
 Amiga 2000 -- 2400 bps -- AmigaUUCP 1.03D     
 ..!watmath!xenitec!wcbcs!lemsys!clemon        
 ..!watmath!xenitec!wcbcs!{AKCS.clemon,_clemon}          
           ^^ Not Reliable Yet                 

po87553@tut.fi (Ojala Pasi Juhani) (03/22/90)

I've PC's hard disk (Seagate ST-251) connected due home made interface to my
A500. I had the same problem with my HD a little time ago. Whenever Amiga
crashed down while saving something (usually something important..),
When I reseted my Amy and Disk Validator noticed that there was something
wrong with the HD, it just used HD a while and said very funny way:

 __________________________________
|System Request ===================|
|__________________________________|
|                                  |
| Device DH0: has read/write error |
|  _____                  ______   |
| |Retry|                |Cancel|  |
| |_____|                |______|  |
|__________________________________|

Uh, funny eh.. and each time I had to use some disk repair program to save
the newest versions of programs and then I formatted HD. About one month ago
I tryed what inhibit-option does. Absolutely nothing, everything was like
HD would had been formatted without inhibit-option. But then I managed to 
crash my Amiga again when HD was busy and the miracle happened! When I 
started my Amy again and it mounted HD, validated it and executed 
startup-sequence! A bit weird, ha..? Does anyone know what inhibit really
does..? I haven't seen any documents for format, so I really don't know
what it inhibits..

Juha Tuominen, Sysop of The Amiga Project
 -- Pasi Ojala, 39230 Osara, Finland --
-- 
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
 Pasi Ojala       Pasbox v2.6     Why does my signature keep changing??
 po87553@tut.fi   C64 forever     Am I doing something wrong?
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

po87553@metso.tut.fi (Ojala Pasi Juhani) (03/23/90)

In article <3279@alva.tut.fi> po87553@alva.tut.fi (Ojala Pasi Juhani) writes:
>...

>I tryed what inhibit-option does. Absolutely nothing, everything was like
>HD would had been formatted without inhibit-option. But then I managed to 

>...

>startup-sequence! A bit weird, ha..? Does anyone know what inhibit really
>does..? I haven't seen any documents for format, so I really don't know
>what it inhibits..
>
>Juha Tuominen, Sysop of The Amiga Project

  I think the main function of Inhibit is just to prevent disk validator to
do it's job. The disk may well be out of order, but disk validator doesn't
notice that because it can't do anythink to disk which is formatted with
inhibit-option.

  You should be aware of that your files no longer are absolutely correct,and
make also file-backups instead of track-backups (as you already do..).

  I hope I am not very wrong about this..




********************************************************************
 Pasi Ojala       The number of people staring at you is straightly
 po87553@tut.fi    proportional to the stupidity of your action. 
********************************************************************

new@udel.edu (Darren New) (03/24/90)

In article <11922@etana.tut.fi> po87553@metso.tut.fi (Ojala Pasi Juhani) writes:
>[...] The disk may well be out of order, but disk validator doesn't
>notice that because it can't do anythink to disk which is formatted with
>inhibit-option.

Not quite.  The INHIBIT option tells the filesystem to ignore the disk
between the time the FORMAT program starts until the time the format 
program ends.  Without the inhibit option, the filesystem ignores the
disk between the time you press return and the time the format program
ends.  The actual formatting of the disk is identical.  The INHIBIT option
is there (I think) to allow disks so corrupt that they crash the filesystem
to be reformatted. I also remember hearing that it is there for compatibility
with when WB calls the formatter. The difference between the described after-
crash behaviors is due to the following:
  write file
		<--- corrupting crash
  write file header
		<--- another corrupting crash
  write directory block
		<--- a crash the validator can automatically recover from
  write free-block bitmaps
		<--- a crash the validator can automatically recover from
  mark bitmap as valid in root block
       
It all depends on whether the crash occured when the disk was in a contradic-
tory state or not. If only the bitmap is bad then the validator will
recreate it by examining all files on the disk.  If there is an inconsistancy
at this time (like two files using the same block, resulting in a
"duplicate key" error) then the validator will tell the filesystem that
the disk is invalid and the filesystem will mark it as readonly, allowing
you to copy the files that are good off the disk before reformatting
(or before running DiskDoctor or DiskSalv or whatever).  Good luck!
		-- Darren