Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!van-bc! From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga.tech Subject: Re: Help: Error Validating Hard Disk! Message-ID: <963@lpami.wimsey.bc.ca> Date: 30 Dec 89 16:50:04 GMT Lines: 54 Return-Path: To: van-bc!rnews In <22906@ut-emx.UUCP>, mwood@ut-emx.UUCP (Matt A. Wood) writes: >I had a system crash while writing to my hard disk, and now my hard >disk does not validate (key 14537 already set, it tells me). I've >run the HDToolBox verify program that came with the drive (A590), and >it finds no bad blocks. Diskdoctor finds a handful of bad blocks, but >the numbers are ~19000, not 14537). I have DiskSalv V1.42, but am >not clear on how it might be used to patch a section of disk (if >it can). A 'key n already set' error is not an indication of a bad block. It is an Amigados error that says you have two hash table entries pointing at the same block, which is illegal to Amigados, and "don't care" to the drive controller. About the only way, currently, that I know of to save the disk without backing up and restoring, is to use something like Sectorama (or DiskX, or DiskEd, or ???), which is a sector editor that allows you to look at the information in any sector on the disk. Unfortunately this does require a knowledge of the file system, and even if you know the file system well, it is tedious, to say the least. What you have to do is find the hash table entries in error. These entries are contained in the root block, user directory blocks, file header blocks, extension blocks, and in the 'hash chains'. You can narrow down the search in many cases by knowing what you were doing when the problem happened. You were writing a file, so the problem is most likely associated with that file. If you copy the file elsewhere (floppy, ram:, etc.) and then use Sectorama to remove it from the directory structure, you might solve the problem. You might also have another problem though, since that block is also part of another path/file, and the result might be a 'funny' directory or a bogus file with parts of two files in it. At least the disk should validate once you have removed the file that was being written. Perform a 'diskchange operation after removing the file, to cause the validator to kick in again. >The question then is: > Do I really have to backup and reformat my hard disk just because the >d*mn system crashed while writing a file?!? Please tell me I don't >have to do this, please! Only if the above desn't work. We don't have the tools for easily doing anything about munged file systems yet. -larry -- " All I ask of my body is that it carry around my head." - Thomas Alva Edison - +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+