Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.sys.ibm.pc
Subject: Re: Stumpers
Message-ID: <25b4793a@ralf>
Date: 17 Jan 90 12:55:06 GMT
Sender: ralf@b.gp.cs.cmu.edu
Organization: Carnegie Mellon University School of Computer Science
Lines: 38
In-Reply-To: <1919@bucket.UUCP>

In article <1919@bucket.UUCP>, leonard@bucket.UUCP (Leonard Erickson) wrote:
}barton@holston.UUCP (Barton A. Fisk) writes:
}>I have found that using ^C to abort a program will sometimes
}>do this [lost clusters] also. But how else to you get out of a dead-lock other
}>that Ctrl-Alt-Del. Perhaps DOS  is not as well behaved as some
}>would lead us to believe.
}
}Actually, the problem isn't DOS in most cases. It is the application programs.
}
}As an example, dBase will cheerfully allocate new clusters to a file, but
}doen't update the filesize entry in the directory until you close the file.
}The improves performance at the expense of safety. If anything goes wrong, 
}the clusters (and the new data) are lost.

That is in fact DOS.  DOS will not update the directory entry for a file until
it is closed.  It wasn't until DOS 3.3 that a call was implemented to force
DOS to update the disk (though there is a way to trick DOS 2.0 and up to
update the disk by closing the file without really closing it).

}Worse, dBase does this by maintaining a copy of the directory in RAM and
}updating it. As many a dBase user has learned to his sorrow, forgetting
}to close a file before swapping disks will not just corrupt that one file,
}but will result in a large portion of the directory of the new disk
}being replaced by the directory of the old disk! Bleah!

Again, this is DOS's doing.  Any program which opens a file is subject to this
corruption if the floppy is swapped while the file is open.  I scrambled a
number of floppies because ProComm 2.4.2's overlay manager keeps the overlay
file open for the entire duration of the program's execution, effectively
requiring you to keep the program disk in the drive at all times.

--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: Ralf Brown 1:129/46
"How to Prove It" by Dana Angluin              Disclaimer? I claimed something?
14. proof by importance:
    A large body of useful consequences all follow from the proposition in
    question.