Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ll-xn!ames!amdahl!kim From: kim@amdahl.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga Subject: Floppy Validation ... some questions and speculation Message-ID: <14049@amdahl.amdahl.com> Date: Thu, 10-Sep-87 21:19:41 EDT Article-I.D.: amdahl.14049 Posted: Thu Sep 10 21:19:41 1987 Date-Received: Sat, 12-Sep-87 11:29:09 EDT Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 111 Keywords: validator validation floppy disk anomoly bugs Tim King AmigaDOS [ 'Yo, 'bro, 'yo line is fried! ] Lately, I've been consolidating some of my archive floppies, and have come across an "anomoly" that I haven't seen mentioned before. I hesitate to call it a *bug*, as it seems to be benign, although the requester messages are a bit misleading, and could confuse people. The environment I use is the CLI, and I load up vd0: (yes, I paid for it!) with most everything I need, and make the proper assignments for c:, s:, and fonts: (though not for devs: or l:). Normally, I don't have the WB floppy in a drive, and so occasionally I get a requester up asking for it, since "something-or-other" is needed by "someone-or-other". [ Short request to the "Keeper of the 1.3 Wish List" at CBM: could we ] [ please be given the option of being told *what* is being asked for, ] [ and by *whom*? Inquiring minds *want* to know ... ] 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). 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)? 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 ... 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? There is one more thing I've noticed that probably has a direct bearing on this "anomoly" ... that is: Immediately after doing a write operation to a floppy (copy, edit, whatever), if I do an "info", sometimes I will see some number of Free sectors listed. If I then do an "info" after the drive activity has stopped, the number of Free sectors will be 1 greater than I saw before. The timing of this has to be just right, and it seems to be more produceable on a nearly full floppy (in fact, I have seen 3 quick calls to "info" produce Free numbers of 8, 7, and 8. Apparently, under "normal" circumstances, information is written to a "spare" sector, and then freed (or, more likely, the sector with the old information is freed). This obviously can't happen with a completely full floppy, so something else has to do the job with a "write in place", and that something else is the *real* Disk-Validator (and not just a "disk validation checker" [in the trackdisk.device ?]). Is that about right? Was this done to preserve the integrity of the floppy to the last possible moment ... or is it a Tim King plot to complicate AmigaDOS :-)? Sorry to get so long-winded and verbose, but I don't like things that behave differently in the "boundary-condition" cases ... especially when I don't understand what's going on! Them's where those "only on Thursdays when the moon is full" bugs like to lurk! Comments? /kim 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 :-) ... -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25