kim@amdahl.amdahl.com (Kim DeVaughn) (09/11/87)
[ '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,25ford@crash.CTS.COM (Michael Ditto) (09/12/87)
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