Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!hao!hull From: hull@hao.ucar.edu (Howard Hull) Newsgroups: comp.sys.amiga Subject: Re: Disk Alignment Keywords: gronk gronk... Message-ID: <4047@ncar.ucar.edu> Date: 22 Aug 89 04:11:49 GMT References: <122819@sun.Eng.Sun.COM> Sender: news@ncar.ucar.edu Reply-To: hull@hao.UCAR.EDU (Howard Hull) Organization: High Altitude Observatory/NCAR, Boulder CO Lines: 55 In article <122819@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >(George Armhold) writes: >> ... Sometimes when I try to boot from a Workbench disk the >>machine just grinds away at the disk. It takes about 5 minutes to boot >>from a disk that usually boots in 3. If I try booting a few times the >>problem sometimes goes away. ... > >What your problem is, is called disk validation... >... >isn't validated an then proceed to read *EVERY* directory and file header >to make sure the bit map is correct. This can take a noticebly long time >especially if you have lots of files on the disk... > GAWRSH, Chuck, you usually get _everything_ when you report the cause of a problem. It's a surprise to see you screw up like this! :-) You should've noted that there's a problem with situations where the Workbench is sooooo full that there's not even a single block left in which to write the new bitmap (keeping in mind that AmigaDOS insists on writing the new bitmap before it "unlinks" the old one). Under such circumstances, AmigaDOS will not write the bitmap until it can find a free block - but since the file writes go ok, it doesn't report any kind of error (that's just as well, since there isn't any error, just a pending operation it can't finish). Thus if you remove your completely full Workbench, it comes out with the bitmap valid flag set to zero (on a 880K floppy that's Root Block (880) longword 78 in the ever so famous track 40). A validated floppy has -1 in this longword. So if you filled your Workbench to where the Info command shows 0 blocks remaining, issue a "DiskChange DF0:" command (assuming DF0's the device where you had the workbench placed) before you pull out the disk - or pull it out and put it back again before you try to reboot with it). DiskChange will cause AmigaDOS to check the root block in order to identify the disk, and will result in a call to the l:Disk-Validator handler when the BMFLAG is found to be cleared. One other thing...if you ever get a disk that causes a crash when you try to Read, Copy or Delete a file or directory you can usually recover (first make a copy of the disk with DiskCopy - but be warned that the copy will crash in the exact same delightful way...). Use a disk editor (i.e., Sectorama, DiskZap, or DiskEd) on the copy to fetch block 880; clear longword 78, correct the checksum, and write the rootblock back to the copy. When the editor releases the disk back to AmigaDos, the validator will be summoned before very much is done with the disk's filesystem, and the problem causing the crash will likely be cleared up before the file system can get involved with it. This procedure will work on disks that are so hosed that they cause a crash upon insertion - if one merly opens the disk editor on a formatted blank disk, and then (after the editor has locked the disk away from AmigaDOS' access) substitute the hosed disk before pulling the root block into the editor's buffer and clearing the BMVALID flag. Have fun... > >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. >"A most excellent barbarian ... Genghis Kahn!" Howard Hull - more barbaric than Genghis Kahn, but not nearly as excellent... hull@hao.ucar.edu