Path: utzoo!attcan!uunet!know!cs.utexas.edu!yale!cs.yale.edu!fischer-michael From: fischer-michael@cs.yale.edu (Michael Fischer) Newsgroups: comp.sys.atari.st Subject: Re: FAT troubles Keywords: NeoDesk, FAT, trouble Message-ID: <27343@cs.yale.edu> Date: 19 Nov 90 14:48:34 GMT References: <1990Nov19.014528.16629@unicorn.cc.wwu.edu> Sender: news@cs.yale.edu Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158 Lines: 43 Nntp-Posting-Host: ginkgo.theory.cs.yale.edu Originator: fischer@ginkgo.CS.Yale.Edu In article <1990Nov19.014528.16629@unicorn.cc.wwu.edu> n8742883@unicorn.WWU.EDU (Perry Pederson) writes: > > Today I was working with unarcing some files while using >NeoDesk 3.0 as my desktop. I put a new disk in the drive and pressed >the ESCape key to tell NeoDesk to read the new disk info and display >the directory. The window refreshed itself with the same info-- for >some reason, the FAT had been written from the disk that was just in >the computer to the new disk I just inserted!! >... > Any suggestions on what could have happened would be appreciated. What happened is pretty clear. TOS failed to recognize the new disk, so it continued using its cached copies of the FAT and directory from the old disk. I'm surprised that the new disk was clobbered unless you actually attempted to write something on it. Why it happened is more of a mystery. The way things are supposed to work is that TOS senses that the medium (disk) might have changed and rereads the boot sector. (The hardware is such that it can't tell for sure.) If the 24-bit disk ID field in the boot sector has changed, then it knows a new disk is in the drive; otherwise, it assumes the same disk is still there. If your two disks had the same disk ID, that would be enough to explain the problem, for then TOS would not know you had switched disks. The TOS desktop and most ST formatters generate a random ID field, so this problem rarely arises. However, some copy programs copy the entire disk, including the ID field, and they can lead to these kinds of problems. Also, I understand that IBM PC's do not use the ID field, so disks formatted on a PC might end up all having the same ID. You didn't say which version of TOS you are using. This problem has been lessened in TOS 1.4. There, I believe that pressing ESC causes TOS to assume a new disk, regardless of whether the ID fields match. With the older version of TOS, pressing escape causes the boot sector to be read and the ID fields to be checked, but a new disk is assumed only if the ID's differ. -- ================================================== | Michael Fischer | ==================================================