Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!news.cs.indiana.edu!ux1.cso.uiuc.edu!ernie!bazyar
From: bazyar@ernie (Jawaid Bazyar)
Newsgroups: comp.sys.apple2
Subject: Re: Reordering GS/OS directories
Message-ID: <1991Jan28.093438.21992@ux1.cso.uiuc.edu>
Date: 28 Jan 91 09:34:38 GMT
References: <1991Jan25.104821.5870@helios.physics.utoronto.ca> <1269@dg.dg.com> <15000@smoke.brl.mil>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: bazyar@cs.uiuc.edu (Jawaid Bazyar)
Organization: Mutation Testing Facility, University of Illinois
Lines: 25

In article <15000@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1269@dg.dg.com> dave@mystie.rtp.dg.com (David Kopper) writes:
>>... GS/OS prevents block I/O requests to a volume that
>>has an open file somewhere on it.
>
>Yes, and it is a ROYAL pain.  Why in the world did Apple DTS decide to
>enforce such a silly restriction and can we get them to PLEASE fix it?

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. Considering
how easily the GS/OS cache can get trashed, it's a GREAT idea.
But that restriction doesn't hold for ReadBlock and WriteBlock, I believe. I'm
pretty sure I used the device level calls (DRead, DWrite, etc) to change my 
boot block so holding OA during boot runs prodos 8 instead of GS/OS.  No, I'm
sure, because I only had the GS/OS exerciser installed as a CDA, and only on
the hard drive.  Yep, I'm positive.  I ran into the (can't access volume)
problem with write block, but I tried DWrite and it worked fine.

And in any case it was software engineering, not DTS that did this.

--
Jawaid Bazyar               | "I'm sure K&R have never heard of Mike." 
Senior/Computer Engineering |
bazyar@cs.uiuc.edu          | "That's okay. I'm sure Mike's never heard of K&R".
   Apple II Forever!        |  (discussion about Orca/C)