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.