🚀 go-pugleaf

barton@holston.UUCP (Barton A. Fisk) writes:

>In article <3404@rti.UUCP>, bcw@rti.UUCP (Bruce Wright) writes:
>> In article <355@marvin.moncam.co.uk>, emmo@moncam.co.uk (Dave Emmerson) writes:
>> The usual way is that the computer got rebooted while there were files open.
>> Could be caused by any number of things:  power failure, hardware problems,
>> program bugs, user error (rebooting at inopportune times in the program).

>I have found that using ^C to abort a program will sometimes
>do this 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.

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!

dBase isn't the only program to be mis-optimized this way. As any of the users
I've had to to explain this to (*after* they blew away their data) would tell
you, they'd rather have it be slower, but do it *safely*.
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Short