Disk Trashing Bug in MS-DOS?

Disk Trashing Bug in MS-DOS?

Post by Bootstra » Sat, 29 Apr 1995 04:00:00



Was browing the computer books in Borders th' other day and came across a
book about how to be a good Windows programmer, avoid pitfals, etc (not
the one from MS, it was from another publisher).  In any case, one of the
suggested techniques was to always close a file in the same message that
the file was opened, since you can't rely on receiving another message in
order to close it.

They then went on and said something like, files that are left open when
the app/OS/computer bombs or shuts down for any reason are what keeps disk
recovery programs like Norton selling so well.  They suggested either
closing the file in the same message or loading the entire file's contents
into RAM and editing them there.  However, our files are too big to do the
latter and, for performance reasons, the former doesn't sound like a great
idea.

So the question is; are these guys on track?  I've worked with lots of
OSs, understand their operation pretty well, and can't really imagine why
this would be a problem?  Assuming that you aren't in the middle of a
write when the crash occurs (and even then it should be unusual), what is
it about simply having an open file when the OS goes down that could trash
part of your disk or munge your directories or FAT?  Is there a problem in
MS-DOS that is responsible for this?

Nathan Tennies
Bootstrap Enterprises Inc

 
 
 

Disk Trashing Bug in MS-DOS?

Post by Andrew Coo » Tue, 02 May 1995 04:00:00



>Was browing the computer books in Borders th' other day and came across a
>book about how to be a good Windows programmer, avoid pitfals, etc (not
>the one from MS, it was from another publisher).  In any case, one of the
>suggested techniques was to always close a file in the same message that
>the file was opened, since you can't rely on receiving another message in
>order to close it.
>They then went on and said something like, files that are left open when
>the app/OS/computer bombs or shuts down for any reason are what keeps disk
>recovery programs like Norton selling so well.  They suggested either
>closing the file in the same message or loading the entire file's contents
>into RAM and editing them there.  However, our files are too big to do the
>latter and, for performance reasons, the former doesn't sound like a great
>idea.
>So the question is; are these guys on track?  I've worked with lots of
>OSs, understand their operation pretty well, and can't really imagine why
>this would be a problem?  Assuming that you aren't in the middle of a
>write when the crash occurs (and even then it should be unusual), what is
>it about simply having an open file when the OS goes down that could trash
>part of your disk or munge your directories or FAT?  Is there a problem in
>MS-DOS that is responsible for this?
>Nathan Tennies
>Bootstrap Enterprises Inc

Well, yes and no - if you've written to the file, and a crash occurs, the file
will probably be corrupted (wont have flushed). If you've extended the file,
and not yet closed it then the DOS directory wont have been updated, but the
FAT will have, so you can see the two will be inconsistent, hence causing
problems. If you are just reading the file, there is no danger at all.
  Andrew.

 
 
 

Disk Trashing Bug in MS-DOS?

Post by Edward J Kalen » Tue, 02 May 1995 04:00:00


: Was browing the computer books in Borders th' other day and came across a
: book about how to be a good Windows programmer, avoid pitfals, etc (not
: the one from MS, it was from another publisher).  In any case, one of the
: suggested techniques was to always close a file in the same message that
: the file was opened, since you can't rely on receiving another message in
: order to close it.

: So the question is; are these guys on track?  I've worked with lots of

If your doing a database or other app that cannot tolerate the file being
in an inconsistant state if the machine should crash, the thing to do is
use the DOS commit function after writing. This will flush all buffers for
that file and make sure the FAT and directory entries are up to date.

The overhead of opening a file every time you want to write to it is too
large to follow these guys advice. Most word processors and speadsheets
fit their ideas since you read them in, manipulate them, then write them
on command. Databases and such that have random access reads and writes
happening fairly regularly simply use the commit function for data
integrity.
--

Ed

 
 
 

1. $$$$$: Trashed my install disk, need VB Pro 3.0 disk #1

Please help!

Need to install old copy of VB 3.0 Pro, and
disk #1 is trashed. Could someone be nice
enough to zip up the files from disk #1
and e-mail it to me.

I have a valid licensed copy, and have already
ordered replacement disks from Microsoft.
However, both diskettes and CD's are backordered,
and they estimate delivery at 3-4 weeks!
(You'd think they could have install disk
images available on their website somewhere!)

I'll gladly reimburse you for any I'net time
and trouble (up to $20 US) if you can deliver
within 24 hours.

Thanks,

Dave

2. Trailblazer Mechanism Works!

3. Win2K: POLSTORE.DLL -- bugs and bugs and bugs

4. Need critique of this logging class

5. BUG BUG BUG / VIRUS VIRUS VIRUS

6. what r vcds

7. BUGS, BUGS, BUGS...HERE IS SOME HELP

8. Symplex RO-1. Anyone using?

9. Can I assign a floppy disk drive letter to a usb disk port driver?

10. "Network Interface" - PDH object trashed

11. Detecting Disk Inactivity/ disk doesn't suspend

12. win 3.0 trashes 386 regs

13. Trashing Memory in MS-Winodws