Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!rochester!cornell!batcomputer!braner
From: braner@batcomputer.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: Rwabs question
Message-ID: <127@batcomputer.tn.cornell.edu>
Date: Sat, 7-Feb-87 00:52:27 EST
Article-I.D.: batcompu.127
Posted: Sat Feb  7 00:52:27 1987
Date-Received: Mon, 9-Feb-87 02:05:44 EST
References: <613@eneevax.UUCP> <550@atari.UUCP>
Reply-To: braner@batcomputer.UUCP (braner)
Distribution: world
Organization: Theory Center, Cornell University, Ithaca NY
Lines: 15
Summary: Is it OK to defeat that kludge?

[]

Since there is media-change sensing via the write-protect widget, is it
OK to defeat that kludge in Rwabs()?  I mean, the desktop sets mediach
to 2 ("definitely changed") each time you close the window, which is
silly, and reduces the utility of my 'scache'.  If I make scache filter
out those calls, am I inviting disaster?

I did something more elaborate to tell GEMDOS that media has changed
in 'flexcopy'  (so the RAMdisk won't kick that 40-folder bug).  Is this
Rwabs() kludge a better way to do it?  I.e., if you do Rwabs(0,0L,2,0,0)
will GEMDOS dismantle its directory tree next time it tries to access
the A: disk?

- Moshe Braner