Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!oxtrap!mudos!mju
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Disk Problem
Message-ID: <601.24D9BF78@mudos.ann-arbor.mi.us>
Date: 4 Aug 89 06:22:23 GMT
Organization: FidoNet node 1:120/129 - Starship Enterprise, Ann Arbor MI
Lines: 43

In article <6159@hubcap.clemson.edu>, rwberry@hubcap.clemson.edu (Robert W Berry) writes:
 >From article <16031@pasteur.Berkeley.EDU>, by chao@cory.Berkeley.EDU 
 >(Chia-Chi Chao):
 >> I understand that the problem is in writing the FAT of Disk #1 onto Disk #2
 >> without recognizing that the disk was changed.  Is there a patch to eliminate
 >> this problem in DOS (I assume that's the problem), or I just have to be more
 >> careful?
 >
 >Sounds like you have experienced the famous DOS buffers dork (FDBD!!!).
 >Check your config.sys file and look for the line
 >     BUFFERS=XX
 >where XX is some integer.  This is a (painfully) limited caching system
 >that DOS uses to speed up disk accesses.  Unfortunately, if DOS caches
 >the FAT and you switch disks, then DOS will write back the updated FAT
 >whenever it has to dump the cache for other information.  End result: a
 >diskette with the FAT of one disk and the data sectors of another.

Wrong-o, although you're close.  DOS will *never* detect a floppy change
if it's sitting at an ARI (Abort, Retry, Ignore) prompt.

Normally, when DOS detects that the floppy has been changed (by monitoring
a status line on the drive -- Can't remember which one), it re-reads the
FAT and destroys its old internal copy, which is now out of date.
Unfortunately, when you are at an ARI prompt, DOS is effectively suspended, 
and ignores anything that the drive tells it.  The moral of this: NEVER, 
EVER, switch disks when you're at an ARI prompt.  Either correct the problem, 
and put the *same disk back in*, and then choose "retry", or choose "abort".
(I suppose that you could also choose "fail" if it's available; this
lets the application know that the operation failed, but it doesn't terminate
the application.)

Unix doesn't have this problem, since it doesn't bother updating anything
unless it is told to (usually via a process called "update" that
issues a "sync" call every 30 sec. or so, or if you umount the device).
If you switch disks under Unix without umounting the device first, you
deserve what you get...

--  
Marc Unangst
UUCP smart    : mju@mudos.ann-arbor.mi.us
UUCP dumb     : ...!uunet!sharkey!mudos!mju
UUCP dumb alt.: ...!{ames,rutgers}!mailrus!clip!mudos!mju
Internet      : mju@mudos.ann-arbor.mi.us