Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!think!mit-eddie!genrad!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!usc-oberon!brand!barad
From: barad@brand.UUCP (Herb Barad)
Newsgroups: net.micro.mac
Subject: Re: Cache bit--retraction & questions
Message-ID: <209@brand.UUCP>
Date: Mon, 5-May-86 15:47:36 EDT
Article-I.D.: brand.209
Posted: Mon May  5 15:47:36 1986
Date-Received: Sat, 10-May-86 12:52:57 EDT
References: <13392@ucbvax.BERKELEY.EDU> <3265@sdcc3.UUCP>
Reply-To: barad@brand.UUCP (Herb Barad)
Organization: U. of So. Calif., Los Angeles
Lines: 30
Keywords: cache

In article <3265@sdcc3.UUCP> borton@sdcc3.UUCP (Chris Borton) writes:
>
>A few people have made the observation that it is *not* a write-through
>cache.  This surprised me somewhat, since it doesn't seem to be keeping with
>Apple's 'safe' policy.  Then again, starting with Finder 4.1 I guess we are
>*supposed* to Shut Down.  It still seems like quite an assumption...

An earlier article that I posted stated that FastEddie2 has problems
using the cache.  I did not realize that the Apple cache was not a
write-through cache.  So the FastEddie2 problem is really Apple's.
You see, FastEddie2 will open a large (>32K) file in separate buffers,
each in its own window.  If you have the cache bit set and the cache
on (as I use to), the editing session will not be "safe" - that is,
many changes especially between buffers may not be saved properly.

Where is the cache handled?  The new ROM's?  Can a "write-through"
INIT patch be posted?
-- 


Herb Barad	[USC - Signal and Image Processing Institute]

USENET:		...!sdcrdcf!usc-oberon!brand!barad			or
		...!mcvax!seismo!sun!trwspf!brand!barad

ARPANET:	barad%brand@USC-ECL.ARPA

USMail:		Univ. of Southern California
		Powell Hall 306, MC-0272
		Los Angeles, CA 90089-0272
		phone: (213) 743-0911