🚀 go-pugleaf

In article <211@actisb.UUCP> federico@actisb.UUCP (Federico Heinz) writes:
...[edited]...
>  A couple of days ago, I formatted a diskette with DCFORMAT, 80 tracks,
>9 sectors, and wrote an MS-DOS boot sector to it. Then I went back to
>the desktop, grabbed three files from the hard disk and placed them over
>the floppy icon. When the copy operation was ready, I opened the floppy
>icon "just to make sure". Good I did: the title bar showed "0 Bytes in 0
>Files", and the window was really empty.

>  The next time the "vanishing copied file" effect showed, I decided to
>inspect the disk.  I found something pretty strange: the boot sector
>information (both TOS and MS-DOS) says that the floppy has 5-sector
>FATs, although 3 sectors would suffice.  Then I discovered why no files
>were found.  The boot sector information said 5-sector FATs and 7-sector
>root directory, in other words:
>
>		Boot sector #:		0
>		First FAT starts at:	1
>		Second FAT starts at:	6
>		Root starts at:		11
>		First avail. cluster:	18
>
>but looking at the first sectors of the floopy I saw that the names of
>the files I had copied were written in sector #7, and that the first
>allocated cluster started in sector #14, which are the correct values
>for a 3-sector FAT disk!
>
>  I have come to some conclusions, but I don't think that I've got the
>complete picture.  I have determined that DCFORMAT's idea of using
>5-sector FATs is a bug, but not a fatal one.  It gives away 2 clusters
>(2 KBytes) that could be used for data, but that's about it, it souldn't
>have any malign effects. It looks like somebody deep in the OS doesn't
>notice this FAT size change, and screws the whole thing up.
>
>  My two questions now are: WHY doesn't my cute little Isabelle (that's
>my Mega's name) notice the FAT size change? And why does this happen
>NOW? It has worked fine all the time until now. The third question is
>why does it happen to ME, but I think this is a bit egocentrical. Any
>ideas?

Yes. In a word: Mediachange.

It is quite probable that you had an MS-DOS disk in the drive with three
sector FATs, removed it, put in an MS-DOS disk with five sector FATs, and
attempted to write on it. This is a sure-fire path to a trashed disk.

MS-DOS does not use disk serial numbers. The ST does. When the ST hardware
detects a possible media change (a state change in the write-protect
sensor), it sets the disk status to "Media-may-have-changed". When the
disk is next accessed, the O/S checks the serial number of the disk to see
if it is the same disk, or if it really has changed. If the serial number
is the same, the O/S concludes that the disk did not change, and continues
read/write operations based on the known disk parameters. In this case,
that meant a disk with three sector FATs.

The MS-DOS disk boot sector contains a field for "O/S-ID", which will contain
something like "IBM 3.2" or "IBM 3.3" or the like. The last three bytes,
the "3.2" or whatever, are the same three bytes the ST uses for the disk
serial number. When you change disks, from one MS-DOS disk to another,
the ST's O/S sees the same serial number, and concludes that the disk has
not been changed. Note that just insuring all your MS-DOS disks are
formatted the same is no solution, since one may have files on it, and
when a change is made, the new disk will not have the same sectors in use.

What to do:

Ounce-of-prevention-method: 
  Don't use MS-DOS boot sectors unless you absolutely have to. They are
  a non-standard disk, as far as the ST is concerned, since they have
  no serial number. 

Pound-of-cure-method:

  1) Label all disks with MS-DOS boot sectors as being MS-DOS disks.
  2) Whenever you remove one from your ST, immediately insert a standard
     format ST disk, and force a read of it (directory, or show info).
     That will insure that a media change has been detected, and that if you
     next insert another MS-DOS disk, another media change will be detected.

Note that a five sector FAT is standard on the ST, and DCFORMAT is providing
you with the standard configuration on the disk. That does not constitute
a bug in DCFORMAT, in my opinion.

*** Bun Warmer ON *** (Weak sort of flame)

Not directed specifically at Mr. Heinz, but at anyone who puts non-standard
anything into any computer, then expects the computer to magically cure all 
their problems.

All computers, from a Sinclair to a Cray, expect to operate in an environment
that conforms to the standards for that system. When you alter their
working environment to something that does not meet their standards, the onus
of insuring that things will work falls directly on you.

For the ST, specifically, standards include 9 sectors per track, 80 tracks,
and unique serial numbers on disks. The utilities built into the ST will
provide disks that meet those standards. It is not reasonable to expect 
that the built in features of the machine can figure out that you have 10
or eleven sectors, 81 or 82 tracks, or all your disks serial numbered the
same.

And I won't start on software that alters system variables directly rather
than via system calls.....

*** CLICK ***


-- 
*George R. Woodside - Citicorp/TTI - Santa Monica, CA 
*Path: ..!{trwrb|philabs|csun|psivax}!ttidca!woodside