Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!cbmehq!cbmger!trebbien
From: trebbien@cbmger.UUCP (Uwe Trebbien GERMANY)
Newsgroups: comp.sys.amiga.tech
Subject: Re: disk "keys"
Message-ID: <150@cbmger.UUCP>
Date: 8 May 90 08:29:42 GMT
References: <37SF02dNa4kc01@amdahl.uts.amdahl.com> <62Gj02bea4fI01@amdahl.uts.amdahl.com>
Reply-To: trebbien@cbmger.UUCP (Uwe Trebbien GERMANY)
Organization: Commodore Bueromaschinen GmbH, West Germany
Lines: 30

In article <62Gj02bea4fI01@amdahl.uts.amdahl.com> dwl10@amdahl.uts.amdahl.com (Dave Lowrey) writes:

>Yes and No. Here is what I found out:
>
>There really are bad headers on the disk. However, these headers are
>NOT part of the filesystem! They are lone sectors, sitting on
>the disk that have header info in them, but are never referenced.


Thats ok. Because they are never referenced only a diskmonitor is able to
find them and will give you that bad key message.

>Since the disk was clean before I reloaded the software, I have no
>idea of where these headers came from. No files should have been
>deleted during re-load, so why are they there?????
>
>Any ideas ?????

I think while formatting there are several bit patterns written to the disk.
It is possible, that the patterns are not the same for the whole disk, using
e.g. incremental values, so that some blocks are interpreted as file headers.

Other possible reason is that directory blocks and bitmaps are updated
several times during reload. You may get this bad key message whenever a
block is referenced by two different headers. Since only one header is
valid the file system won't worry, but a disk monitor will find that second
reference.


best regards		UWE