chao@cory.Berkeley.EDU (Chia-Chi Chao) (08/04/89)
I have damaged two floppies when writing/copying files. Fortunately, I was able to recover most of the data. I have reproduced this problem on three computers (PC and AT clones) with DOS 3.2/3.3: 1. Disk #1 with some files, say File1 and File2 -- write protected. Disk #2 with File3 and File4 -- not write-protected. 2. Copy File5 to Disk #1 -- but intended for Disk #2. 3. DOS reports write-protect error -- Abort, Retry, Fail? 4. Swap Disk #1 with Disk #2 and use Retry. 5. Disk #2 ends up with unuseable File1 and File2 headers and good File5. File3 and File4 are no longer recognized. 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? Thanks for any information. Chia-Chi chao@cory.berkeley.edu
rwberry@hubcap.clemson.edu (Robert W Berry) (08/04/89)
From article <16031@pasteur.Berkeley.EDU>, by chao@cory.Berkeley.EDU (Chia-Chi Chao): > ... > 1. Disk #1 with some files, say File1 and File2 -- write protected. > Disk #2 with File3 and File4 -- not write-protected. > 2. Copy File5 to Disk #1 -- but intended for Disk #2. > 3. DOS reports write-protect error -- Abort, Retry, Fail? > 4. Swap Disk #1 with Disk #2 and use Retry. > 5. Disk #2 ends up with unuseable File1 and File2 headers and good File5. > File3 and File4 are no longer recognized. > > 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. You don't have this problem if you are using a fixed disk (since you can't switch media while the FAT is in cache.) I've seen countless disks trashed this way (although I thought the problem was fixed as of MS-DOS 3.2) usually belonging to well-meaning neophytes trying to tweak a little more performance out of their PC. I generally tell people not to use the BUFFERS option in their config.sys, or if they must have a cache, to use a reputable third party caching program such as DiskQuick of PC-Cache. > > Thanks for any information. Chia-Chi chao@cory.berkeley.edu Hope this helps, (tm) Bob -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=- Bob Berry -=- PC-Guru's Inc. ! rwberry@hubcap.clemson.edu -=- -=- We are the science of modern motion. ! 803-654-7623 || 803-656-2635 -=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
mju@mudos.ann-arbor.mi.us (Marc Unangst) (08/04/89)
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
chao@cory.Berkeley.EDU (Chia-Chi Chao) (08/04/89)
In <6159@hubcap.clemson.edu> rwberry@hubcap.clemson.edu (Robert W Berry) writes: > >Check your config.sys file and look for the line > BUFFERS=XX >where XX is some integer. This is a (painfully) limited caching system > >I generally tell people not to use the BUFFERS option in their >caching program such as DiskQuick of PC-Cache. The problem also occurred on a PC clone booted up with no Config.Sys. Therefore, BUFFERS is set to default (2?). I received a reply from Microsoft saying this is a very well known problem. I guess if they don't know a fix to this (without rewriting DOS), I just have to watch what I do with floppies. Thanks. Chia-Chi
nts0302@dsacg3.UUCP (Bob Fisher) (08/04/89)
From article <16031@pasteur.Berkeley.EDU>, by chao@cory.Berkeley.EDU (Chia-Chi Chao): > I have damaged two floppies when writing/copying files. Fortunately, I was > able to recover most of the data. I have reproduced this problem on three > computers (PC and AT clones) with DOS 3.2/3.3: > > 1. Disk #1 with some files, say File1 and File2 -- write protected. > Disk #2 with File3 and File4 -- not write-protected. > 2. Copy File5 to Disk #1 -- but intended for Disk #2. > 3. DOS reports write-protect error -- Abort, Retry, Fail? > 4. Swap Disk #1 with Disk #2 and use Retry. > 5. Disk #2 ends up with unuseable File1 and File2 headers and good File5. > File3 and File4 are no longer recognized. > > 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? The problem here is operator error, not program bug (no flame intended). To update a file, the system must read directory and space allocation data from the disk, change it for the new file, and write it back. When you respond "retry", the system does not know that you changed disks and uses the information read from the first attempt. When you change disks, the information from the first disk is updated and written to the second disk. Since part of the information may be sectors allocated to used files or free space, you not only trash information in the FAT and directory information, but maybe overwrite sectors belonging to other files. To avoid this, you need to tell the system to reread directory/allocation data. There is no response for this. The only way to do it is to abort, change disks and then re-execute the command/program. -- Bob Fisher (osu-cis!dsacg1!bfisher) 614-238-9071 (Autovon 850-9071) From the Internet: bfisher%dsacg1.uucp@daitc.arpa US Defense Logistics Agency Systems Automation Center DSAC-TSX, Box 1605, Columbus, OH 43216-5002
du4@mace.cc.purdue.edu (Ted Goldstein) (08/04/89)
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): >> ... >> 3. DOS reports write-protect error -- Abort, Retry, Fail? >> 4. Swap Disk #1 with Disk #2 and use Retry. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Funny you should mention that, I just happened to be browsing through DOS 3.3 Users Guide yesterday and came across the following tidbit (on page A-1) about the Abort, Retry, Ignore, Fail? message: *WARNING: If either of these messages appears for a diskette drive, DO NOT change disks before responding with A,R,I or F. So it would appear that Microsoft is at least aware that the hazard exists, but I will admit that yesterday was the first time I ever got around to actually opening the users guide booklet that came with the larger reference manual. Ted Goldstein Purdue University School of Technology du4@mace.cc.purdue.edu
joe@pnet51.cts.com (Jim Henderson) (08/05/89)
Just out of curiosity, what happens if you include the line BUFFERS = 0 in your CONFIG.SYS file? Does it still default to 2? Jim Henderson, joe@pnet51.cts.com "Don't ask me how it works or I'll start to whimper." - Arthur Dent DISCLAIMER: "I speak for myself, and only for myself." (Except where noted.)
chao@cory.Berkeley.EDU (Chia-Chi Chao) (08/06/89)
In article <827@orbit.UUCP> joe@pnet51.cts.com (Jim Henderson) writes: >Just out of curiosity, what happens if you include the line > > BUFFERS = 0 > > in your CONFIG.SYS file? Does it still default to 2? Yes, setting BUFFERS=0 results in the default number of buffers. On my machine, the default is 15.
huilin@hpindda.HP.COM (Hui Lin Lim) (08/08/89)
/ rwberry@hubcap.clemson.edu (Robert W Berry) / 4:46 pm Aug 3, 1989 / writes >From article <16031@pasteur.Berkeley.EDU>, by chao@cory.Berkeley.EDU (Chia-Chi Chao): >> ... >> 1. Disk #1 with some files, say File1 and File2 -- write protected. >> Disk #2 with File3 and File4 -- not write-protected. >> 2. Copy File5 to Disk #1 -- but intended for Disk #2. >> 3. DOS reports write-protect error -- Abort, Retry, Fail? >> 4. Swap Disk #1 with Disk #2 and use Retry. >> 5. Disk #2 ends up with unuseable File1 and File2 headers and good File5. >> File3 and File4 are no longer recognized. >> >> 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. > >You don't have this problem if you are using a fixed disk (since you >can't switch media while the FAT is in cache.) > >I've seen countless disks trashed this way (although I thought the >problem was fixed as of MS-DOS 3.2) usually belonging to well-meaning >neophytes trying to tweak a little more performance out of their PC. > >I generally tell people not to use the BUFFERS option in their >config.sys, or if they must have a cache, to use a reputable third party >caching program such as DiskQuick of PC-Cache. > I believe that this isn't a problem caused by BUFFERS but simply because DOS doesn't expect you to change the disk while in it's error recovery mode. I.e. don't change floppies as you as you have the Abort,Retry,ignore message prompting you for a response (especially when it was a write that failed). Hui-Lin Lim ARPA: huilin%hpinddf@hplabs.hp.com UUCP: {ucbvax,hplabs}!hpinddf!huilin Phone: (408)447-2835
stel@tank.uchicago.edu (stelios valavanis) (08/08/89)
In article <1569@dsacg3.UUCP> nts0302@dsacg3.UUCP (Bob Fisher) writes: >From article <16031@pasteur.Berkeley.EDU>, by chao@cory.Berkeley.EDU (Chia-Chi Chao): >> I have damaged two floppies when writing/copying files. Fortunately, I was ..... >> 3. DOS reports write-protect error -- Abort, Retry, Fail? >> 4. Swap Disk #1 with Disk #2 and use Retry. >> 5. Disk #2 ends up with unuseable File1 and File2 headers and good File5. >> File3 and File4 are no longer recognized. >> >> I understand that the problem is in writing the FAT of Disk #1 onto Disk #2 > >The problem here is operator error, not program bug (no flame intended). too apologetic >you respond "retry", the system does not know that you changed disks and on some (surprisingly popular) operating systems >To avoid this, you need to tell the system to reread directory/allocation >data. There is no response for this. The only way to do it is to abort, >change disks and then re-execute the command/program. sorry to be so negative about this but this is one area that the mac pins down the PC no prob. the mac always know what disk is in its drive and even keeps track of disks you want active without being in the drive. you can throw in random disks all you want, it will keep asking for the one it wants untill it gets it! stel -- Bitnet: stel%tank.uchicago.edu@uchimvs1.bitnet | i don't know Internet: stel@tank.uchicago.edu | YOU don't know? uucp: ...!uunet!mimsy!oddjob!tank!stel | ok, so i don't know