Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!zephyr.ens.tek.com!tekgen!sail!toma From: toma@sail.LABS.TEK.COM (Tom Almy) Newsgroups: comp.os.msdos.misc Subject: Re: FASTOPEN (was Another QEMM problem.) Message-ID: <9478@sail.LABS.TEK.COM> Date: 7 May 91 15:35:15 GMT References: <9043@crash.cts.com> <1991May5.194030.2078@clmqt.marquette.Mi.US> <1991May6.080323.6898@msuinfo.cl.msu.edu> <1991May6.131604.16735@maytag.waterloo.edu> Reply-To: toma@sail.LABS.TEK.COM (Tom Almy) Organization: Tektronix, Inc., Beaverton, OR. Lines: 38 In article <1991May6.131604.16735@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: >In article <1991May6.080323.6898@msuinfo.cl.msu.edu> draper@buster.cps.msu.edu (Patrick J Draper) writes: >>I'd say that the man was right on when he said to stay away from >>fastopen, but you are right about share. It causes problems as well, and >>if you don't use software that handles the disk using FCB's, you're OK >>without it. > >Exactly what uses of share cause problems? Command.com uses FCB's when it >deletes files; is this safe without share? Writing to files using FCBs is the only dangerous problem. You can't always read from files using FCBs either, but that usually is not dangerous. I also agree not to use FASTOPEN, but to use a good disk caching program. In the spirit of NOSHARE.COM (which I wrote), I am now offering SLOWOPEN.COM, a safe replacement for FASTOPEN, that is designed to be used with a disk cache. I believe you will find that the combination of SLOWOPEN+cache (other than Microsoft's SMARTDRIVE) is superior to using FASTOPEN. section 1 of uuencode 3.16 of file slowopen.com by R.E.M. begin 644 slowopen.com MZ0@`@0$`````"@"\FO_'!@4!F/^]_O^)+@7P'-(<.)P8G:BQY?`;1`S2'#! `` end sum -r/size 54831/211 section (from "begin" to "end") sum -r/size 13630/129 entire input file (BTW, this program posted as a joke, don't bother to archive!) -- Tom Almy toma@sail.labs.tek.com Standard Disclaimers Apply