Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!genrad!decvax!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac
Subject: Re: Possible LSC improvements
Message-ID: <21257@ucbvax.BERKELEY.EDU>
Date: Tue, 13-Oct-87 15:39:28 EDT
Article-I.D.: ucbvax.21257
Posted: Tue Oct 13 15:39:28 1987
Date-Received: Thu, 15-Oct-87 05:11:16 EDT
References: <2071@sfsup.UUCP| <170026@acf3.NYU.EDU>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 23

In article <2638@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes:

>  But I am hesitant to use RAM cache when
>I am debugging tricky code that is crashing a lot; I worry about losing
>source changes that have not been written from the cache out to disk.  

Well, you can stop worrying. LightSpeed C asks you, before you run a
project "Save Changes before running?" just press the write button and
it will write the changes to disk.

Apple has always said that programs must call FlushVol() after writing
a file so that the directory information will be updated.  Apple
designed the RAM cache so that calling FlushVol() flushes the cache
and ensures that the write really gets put on the disk.  Assuming that
LightSpeed C's write routine plays by the rules, your changes are
safe.

This point is more fully described in my upcoming "How to Write a TEXT
Editor, part II, Data File compatibility."

--- David Phillip Oster            --A Sun 3/60 makes a poor Macintosh II.
Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu