Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!dsacg1!dsacg3!nts0302
From: nts0302@dsacg3.UUCP (Bob Fisher)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Disk Problem
Message-ID: <1569@dsacg3.UUCP>
Date: 4 Aug 89 12:46:10 GMT
References: <16031@pasteur.Berkeley.EDU>
Distribution: na
Organization: Defense Logistics Agency Systems Automation Center, Columbus
Lines: 39

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