Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!sun!imagen!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st.tech Subject: Re: Disabling FAT/Directory cache Message-ID: <2951@atari.UUCP> Date: 28 May 91 19:04:36 GMT References: Organization: Atari Corp., Sunnyvale CA Lines: 37 danny@fiction.ms.sub.org (DanielRoedding) writes: >7103_2622@uwovax.uwo.ca (Eric Smith) writes: >> Is there a nice way to tell TOS (version 1.4 and higher) *not* to >> cache a drive? I want to share a drive over a network; clients >> will see the drive as read-only, but I'd like the server to be able to >> write to the drive. >Since you have to write a little device driver, you also have to take care >of the media change state. If you return 2 all the time at Mediach() calls, >TOS should not keep old information it it's caches. If you return 2 on every call, then you could never do anything: 2 means HAS CHANGED, and all open handles on the drive are closed. Subsequent accesses with those handles would return EIHNDL (invalid handle). Even if you return 1 and find that GEMDOS always re-reads the sectors, this will be REALLY SLOW, because TOS uses Mediach() to validate its cache buffers, and it happens A LOT in some cases. Example: for each Fsfirst/Fsnext call in a directory search, you'll get at least one Mediach() call. If you actually had to read the sector over the net for each call, it would be unbelievably slow. I don't know a way to cache a drive from outside. You're better off using MetaDOS to catch the calls at the filesystem level rather than the BIOS level. If a call is destined for a remote filesystem you make it a remote procedure call at the top level, not the record level. Eric, aren't you running MiNT? You already have the capability: just mount it like you do a Minix filesystem and make remote procedure calls at that level. You could even do local caching and make remote calls like, "Are my cached buffers still valid?" to reduce your net traffic. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt