steve@clmqt.marquette.Mi.US (Steve Lasich) (05/06/91)
In article <9043@crash.cts.com> dang@crash.cts.com (Dan Gookin) writes: >On the merits of FASTOPEN: > >> DO NOT USE THIS COMMAND! << >FASTOPEN is a half-ass attempt at disk caching, only caching file names >and their locations. It will seriously mess with your disk, and I've >recommended in that last three DOS books I've written that no one >should use FASTOPEN. DO NOT USE DISK OPTIMIZERS OR FOLLOW ADVICE IN BOOKS Disk optimizers that remap files will mess with your disk. Fastopen won't. If you optimize your disk you should reboot your computer before you do anything else. ESPECIALLY if you use Fastopen. Most reputable disk optimizers will reboot for you anyway upon termination. This is the only problem I've ever seen after years of using Fastopen with DOS 3.3 and 4.x. >Some dealers will use INSTALL to setup FASTOPEN in CONFIG.SYS, especially >on DOS 4 systems. Remove it. Also, if you've ever experienced any >problem with DOS insisting you always use the same floppy diskette, >blame FASTOPEN.. You can "blame" Fastopen. Some people might even believe you. I ran into this problem with 50 Zenith 386 machines: "Invalid Disk Change in Drive A--Abort, Retry or Fail." This also translates into "Disk Error 34" in Word Perfect. It turned out SHARE was the determining factor in the error. Remove SHARE and no error. Fastopen does not cache floppies. It only caches file names on the drive specified in the command line. Did you do this thorough of a research job on all three books? >dang. Steve Lasich, Microcomputer Lab Coordinator acsl@bitnet Northern Michigan University steve@clmqt.marquette.mi.us
draper@buster.cps.msu.edu (Patrick J Draper) (05/06/91)
In article <1991May5.194030.2078@clmqt.marquette.Mi.US> steve@clmqt.marquette.Mi.US (Steve Lasich) writes: >In article <9043@crash.cts.com> dang@crash.cts.com (Dan Gookin) writes: > DO NOT USE DISK OPTIMIZERS OR FOLLOW ADVICE IN BOOKS > >Disk optimizers that remap files will mess with your disk. Fastopen >won't. If you optimize your disk you should reboot your computer >before you do anything else. ESPECIALLY if you use Fastopen. Most >reputable disk optimizers will reboot for you anyway upon termination. >This is the only problem I've ever seen after years of using Fastopen >with DOS 3.3 and 4.x. > You are VERY lucky then. I've run into many many (too many to count) problems with fastopen. It's always the same old story. Program x won't run on the computer a, but it will run on b. The difference? Fastopen. Remove fastopen, and it runs on both computers. So, I'll correct the boldface to say: USE GOOD DISK OPTIMIZERS AND USE YOUR HEAD WHEN FOLLOWING ANY ADVICE (but don't touch fastopen with a 20 foot pole) >You can "blame" Fastopen. Some people might even believe you. I ran >into this problem with 50 Zenith 386 machines: "Invalid Disk Change in >Drive A--Abort, Retry or Fail." This also translates into "Disk Error >34" in Word Perfect. It turned out SHARE was the determining factor in >the error. Remove SHARE and no error. Fastopen does not cache >floppies. It only caches file names on the drive specified in the >command line. > >Did you do this thorough of a research job on all three books? 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. > >>dang. > >Steve Lasich, Microcomputer Lab Coordinator acsl@bitnet >Northern Michigan University steve@clmqt.marquette.mi.us ------------------------------------------------------------------------ Patrick Draper "College is supposed to prepare you for the future, cps.msu.edu but all my future's behind me." draper@cps.msu.edu -- My GrandPa, age 85, Fall 1990 graduate of Western Michigan University ------------------------------------------------------------------------
dmurdoch@watstat.waterloo.edu (Duncan Murdoch) (05/06/91)
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? Duncan Murdoch P.S. I've set followups to comp.os.msdos.misc; this doesn't have anything to do with DV any more.
draper@buster.cps.msu.edu (Patrick J Draper) (05/07/91)
In article <1991May6.131604.16735@maytag.waterloo.edu> dmurdoch@watstat.waterloo.edu (Duncan Murdoch) writes: > >Exactly what uses of share cause problems? Command.com uses FCB's when it >deletes files; is this safe without share? > >Duncan Murdoch > >P.S. I've set followups to comp.os.msdos.misc; this doesn't have anything to >do with DV any more. This is my understanding, and someone will correct me if I'm wrong. FCB's can handle only 32 MB of disk space, and if you try to write a file beyond that, the FCB will 'wrap around' and trash the disk. I believe that the reason deletes work alright is that on most disks, the partition, FAT's and directories are located in the first 32Megs of the drive. ------------------------------------------------------------------------ Patrick Draper "College is supposed to prepare you for the future, cps.msu.edu but all my future's behind me." draper@cps.msu.edu -- My GrandPa, age 85, Fall 1990 graduate of Western Michigan University ------------------------------------------------------------------------
toma@sail.LABS.TEK.COM (Tom Almy) (05/07/91)
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^)+@<!_.@%`+@`3,TAZ!H`%E-L;W=/1 M<&5N($E.4U1!3$Q%1"`Z+2GI$@!;B@<PY$-34`'#6%I3B=/I(0"X#0#H"0"XY G"@#I`P`!``"B80&T0+D!`+IA`8L>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