Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!dlyons From: dlyons@Apple.COM (David A. Lyons) Newsgroups: comp.sys.apple2 Subject: Re: Reordering GS/OS directories Message-ID: <48799@apple.Apple.COM> Date: 4 Feb 91 01:01:38 GMT References: <15000@smoke.brl.mil> <1991Jan28.093438.21992@ux1.cso.uiuc.edu> <15006@smoke.brl.mil> Organization: Apple Computer Inc., Cupertino, CA Lines: 33 In article <15006@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <1991Jan28.093438.21992@ux1.cso.uiuc.edu> bazyar@cs.uiuc.edu (Jawaid Bazyar) writes: >>Doug, Doug, Doug. Surely you jest. It's only good common sense to >>prevent low level block I/O requests to a volume with open files. > >No, it's stupid. It assumes that the programmer does not know what he >is doing. While this may be true for Macintosh USERS, it should not >be assumed of Apple IIGS PROGRAMMERS. Our tools have been deliberately >crippled! You *can* use DRead and DWrite even on volumes with open files. You have to be Very Careful, though--there is no obvious way to determine whether an FST has its own copies of the data in some of those blocks. You could confuse an FST into corrupting the disk, if you mess with any block related to an open file. (By the way, the GS/OS Cache is not the issue here--that's flushed to disk automatically on a DWrite. The issue is that an FST can have its own private copies of the blocks it currently cares about.) I *do* think it would be good to have a supported way of "unmounting" a volume so that no FST knows about it; but this wouldn't help a whole lot, because your boot volume would still have an open file (Sys.Resources) and you would not be able to unmount it. -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II System Software Engineer | P.O. Box 875 America Online: Dave Lyons | Cupertino, CA 95015-0875 GEnie: D.LYONS2 or DAVE.LYONS CompuServe: 72177,3233 Internet/BITNET: dlyons@apple.com UUCP: ...!ames!apple!dlyons My opinions are my own, not Apple's.