Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!hao!hull From: hull@hao.ucar.edu (Howard Hull) Newsgroups: comp.sys.amiga Subject: Re: Another visit to the guru... Summary: The quest for speed is what's responsible for this... Keywords: BMFLAG Message-ID: <1368@ncar.ucar.edu> Date: 5 Feb 89 22:25:09 GMT References: <8902040631.AA03787@jade.berkeley.edu> Sender: news@ncar.ucar.edu Reply-To: hull@hao.UCAR.EDU (Howard Hull) Organization: High Altitude Observatory/NCAR, Boulder CO Lines: 54 This time I'll give everyone a break and list the advice first, then I'll go on with the commentary... If you put a disk into your Amiga and your Amiga comes up with a meditation alert, then remove the disk, and (after reboot) substitute a known good blank formatted disk in an available drive, then call up a disk editor (DiskEd or DiskZap are both good ones). Now put in the troublesome disk, re-determine the root block (if possible), read it in, and clear the BMFLAG at longword SIZE-50. (The BMFLAG should be at longword decimal 78 on an AmigaDOS floppy, I believe.) Write the root block back to the disk, and exit the editor. AmigaDOS should open the disk, find the BMFLAG is cleared, and then proceed to pounce on it with the Disk Validator. Most of the time this will succeed, clearing up whatever problem you may have had with the disk. So here's the commentary: I discovered fragile elements in AmigaDOS <-- see, no G. Do I got respect? when I stupidly tried to "bcopy" a block from one disk to another "nearly identical disk" with DiskZap. When I checked out of DiskZap I was instantly gonged by the Guru. Then I remembered that (in the name of speed) trackdisk writes the whole track, not just the block. A little more thinking about the problem and a quick look at Bantam's "The AmigaDOS Manual" (not necessarily in that order) revealed to me that the track I had copied contained the disk bitmap. I had swapped in a track containing an invalid bitmap (for the mounted disk, anyway), and this had included also the rootblock with a TRUE BMFLAG. It was then that I realized what was the programmers' method of providing for "the need for speed" in AmigaDOS - by following rules of consistency rather than (as Leo said in his recent commentary) "making the program bullet proof" by using elaborate internal checks (which would come with resultant degradation in the speed and the size of the system routines). At first I was upset about this, thinking as you did, something of the effect "It ought not to be possible to crash the system by merely inserting a disk!" But then, think of the price. So I suppose that's why we have rules. If everyone obeys them, things are quicker and simpler. We don't have anything in the society that actually keeps motorists from running red lights. If we find a motorist who does this consistently, we eventually gronk 'em. In the case of AmigaDOS we either re-format the disk, or kick serious bitmap with a file system rectification tool. The trouble with Warp and programs of that ilk is that they violate the "virtual semaphores" built into AmigaDOS by doing things non-atomically. In other words, all it takes is a power fail or a snatched disk, and *ka-wump* they are caught with a set BMFLAG and an invalid bitmap. Quite a lot in AmigaDOS is protected by a few early-on consistency checks (like checking the BMFLAG before reading disk blocks into template-oriented routines that rip right into it and DO THINGS based on what was read) and by appropriately atomic clean-up actions like not letting anyone do anything with the disk as a part of a file-write until the BMFLAG is cleared, the file is written, the bitmap is updated, and the BMFLAG is set again. For a newly inserted corrupt disk with a set BMFLAG, if the blocks are hosed, and addresses are computed with the available garbage, a GURU visit is the inevitable result. Howard Hull hull@hao.ucar.edu