Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!hplabs!hp-sdd!ncr-sd!crash!ford From: ford@crash.CTS.COM (Michael Ditto) Newsgroups: comp.sys.amiga Subject: Re: Floppy Validation ... some questions and speculation Message-ID: <1697@crash.CTS.COM> Date: Sat, 12-Sep-87 08:23:32 EDT Article-I.D.: crash.1697 Posted: Sat Sep 12 08:23:32 1987 Date-Received: Sun, 13-Sep-87 09:46:07 EDT References: <14049@amdahl.amdahl.com> Reply-To: ford@crash.CTS.COM (Michael Ditto) Organization: Crash TS, El Cajon, CA Lines: 103 Keywords: validator validation floppy disk anomoly bugs Tim King AmigaDOS In article <14049@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: > [...] >Anyway, something unusual happens when you *exactly* fill up a floppy ... or, >more precisely, something *doesn't* happen. After the write takes place that >used up the final sector, the floppy seems perfectly OK ... files can be >deleted or read, and "info" correctly tells you that 1758 sectors are used, >and 0 are free. > >Now, if this full floppy (I'll call it "Foo:") is ejected, then the next time >it is reinserted (immediately, or much later), up will pop a requester asking >for the WB ("Please replace volume Workbench in any drive"). > >Feeding it the WB causes "something-or-other" to be read from it, and then >Foo: will spin for awhile, presumably getting something updated. After this >process, Foo: behaves quite normally, and subsequent insertions don't bring >up a requester. Obviously something that normally happens after a file is >written, *doesn't* if that file uses up the last available sector (but you >don't get told about it then). There is a bug in the AmigaDOS filesystem handler that causes an exactly filled disk to be marked as "needing validation". I have reported this bug to Commodore. Usually, when a disk is written to, the DOS will "fix up" the disk structure to reflect the new changes (such as blocks that are no longer free, etc.). But until the disk has been "fixed", it is marked as "needing validation" so that if a user removes the disk in the middle of an update, it will be fixed as much as possible next time it is put in. The bug is that the disk is LEFT in this "needing validation" state if the operation exactly filled the disk. It is particularly noticeable if you do this and then remove and write-protect the disk. It is then "locked" in this "needing validation" state, and will cause the disk validator to run whenever it is put into a drive. It will be fixed if you write-enable it and let the disk validator fix it up. >If, on the other hand, you click "Cancel" on the initial requester, up pops >a 2nd requester that says, "Error validating disk Foo: Unable to load disk >validator". Huh? I thought floppies were *always* validated on insertion >(ever enter "info" before the drive quits whirring on an insertion and see >"Validating YourFloppyLabel" in the Status area)? Are there two parts to >"l:Disk-Validator"? One part that stays memory resident, and one part that >doesn't (which does fix-ups)? There is a simple validator that just gives the disk a quick look and makes sure its status is set to "ok". I don't beleive it ever writes to the disk. If the status is not "ok", it runs the figure-out-the-disk-and-fix-it-up- and-set-its-status version of the validator. This part is in l:Disk-Validator. >To continue ... clicking "Cancel" on the 2nd requester brings up yet a 3rd >requester: "Disk structure corrupt Use DISKDOCTOR to correct it". Bull! >This is misleading, though I suppose it can be argued that if I'd fed it >the WB when it 1st asked for it, I wouldn't be seeing this requester. As >may be ... This is a "generic" message printed whenever the validator fails. Usually, it is correct becuase usually the validator gets as far as being loaded into memory and looking at the disk. >Hitting "Cancel" now completes the string of requesters, and we're left at >the CLI. Enter "info" now and it will always say "Validating Foo" for that >drive. Doing a "cd" to that drive works OK, as does a "dir" of it. And >you can "type" a file, or execute a program. > >You cannot however save an edited file (even though the file has been reduced >in size) ... you get a requester that says: "Volume Foo: is not validated". >Nor can you "delete" a file, as you get the same requester, and then a CLI >error message from the (Amiga's) "Delete" command: "Not Deleted - disk not >validated". > >OK, OK ... so the floppy didn't get validated! Why not? Why can some >commands operate on the files of a "not validated" disk, and some cannot. >What is being picked up off the Workbench floppy to fix-up Foo: (yes, I >know it's probably the l:Disk-Validator, but then what is it that normally >validates floppies)? And why is it needed just for this special case? >Also, the "whatever-it-is" seems to always have to come from the WB *disk*, >even when the experiment is repeted several times in a row, and I have >lots of Facc (paid for it, too!) buffers, and haven't removed the WB. Why? Not-validated disks can be read, but not written to. Most disks are kept "validated" at all times by writing to their root block after any series of accesses. The DOS has all the info about the disk already in memory, so it just needs to update a few bytes here or there. If this does not happen for some reason, (like the disk is pulled out too soon, or the exactly-full bug happens), the disk can not be validated using the already- in-memory info, so instead, the info must be re-built by analyzing the disk next time it is inserted. >P.S. If anybody suggests I should RTFM, please tell me where. I find no > mention of the validation process or related topics in the AmigaDOS > Manual, the RKM's, or elsewhere ... of course I could have missed a > paragraph somewhere :-) ... Validation is mentioned briefly in section 1.5 of the AmigaDOS User's Manual (page 21 of the Bantam Books version), and the "Bitmap valid flag" (BMFLAG) is mentioned in the Filing System chapter of the AmigaDOS Technical Reference Manual. But it is generally undocumented, and most of what I explained above was determined empirically. -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu