federico@actisb.UUCP (Federico Heinz) (04/29/88)
There are times when I wish I had taken kite construction or chess as a hobby. But I've chosen computers, and sometimes things like this happen. 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. I tried again (starting at the formatting stage), the same thing happened, the third time it worked. By the same time, some weird things started to happen whit my floppy drive: one and the same disk would show, when inserted, either absolute garbage (filenames with commas, arrows, happy faces, etc) or the correct directory. 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? -- Federico Heinz "In Dubio Pro Libido" BIX: fheinz | Beusselstr. 21 UUCP: ...!unido!tub!actisb!federico | 1000 Berlin 21 Tel: (030) 396 77 92 | F.R. Germany.
apratt@atari.UUCP (Allan Pratt) (05/03/88)
From article <211@actisb.UUCP>, by federico@actisb.UUCP (Federico Heinz): > ... 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, ... > > 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! Does your formatter put a unique (or at least random) serial number on the disk, even when you ask for an MS-DOS boot sector? If it doesn't, you're in trouble. The ST checks the serial number AND NOTHING ELSE to detect media change, and if the serial number is the same, it doesn't reload any of the other information. So if a disk goes from a three- sector FAT to a five-sector FAT without changing its serial number, the ST won't know of the change. Incidentally, the format code *is* smart enough to set the media's state to "maybe changed" when you format or write to the boot sector. But if the serial number is the same, the state goes from "maybe" to "not changed" without reloading the BPB. Does MS-DOS *require* the words MS-DOS (or something) in the "OEM" field? It's the last three bytes of this field which TOS uses for the serial number. I know three sectors is enough for a FAT. One possible explanation for the five-sector FAT is so on a double-sided disk, the first sector of the root directory is on Side 1, not Side 0. Otherwise, you could use a single-sided drive to write to a double-sided disk, until you actually tried to write the data: the file-create could succeed. That is just one hypothesis; only apple!landon knows for sure. But whether he thought of it or not, it's sufficient justification for me to keep that "feature" in GEMDOS. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
woodside@ttidca.TTI.COM (George Woodside) (05/03/88)
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
braner@batcomputer.tn.cornell.edu (braner) (05/04/88)
[] The utility IBMFMT, which formats MS-DOS disks on the ST, in its later version (1.1?), does overwrite the critical 3 bytes with a random serial number. MS-DOS does not seem to mind, and it's safer on the ST side. (I have no idea what DCFORMAT does.) The ST doesn't mind 3-sector FATs either. - Moshe Braner PS: still looking for a used 520ST system.