From: Nate Eldredge <neldredge AT hmc DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Corruption of read-only files on program crash
Date: 08 Dec 1999 13:40:32 -0800
Organization: InterWorld Communications
Lines: 25
Message-ID: <83ln75cdrj.fsf@mercury.st.hmc.edu>
References: <82l8ll$4h2 AT romeo DOT logica DOT co DOT uk>
NNTP-Posting-Host: mercury.st.hmc.edu
X-Trace: nntp1.interworld.net 944689271 99663 134.173.45.219 (8 Dec 1999 21:41:11 GMT)
X-Complaints-To: usenet AT nntp1 DOT interworld DOT net
NNTP-Posting-Date: 8 Dec 1999 21:41:11 GMT
X-Newsreader: Gnus v5.7/Emacs 20.4
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"Chris Underwood" <underwoodc AT logica DOT nospam DOT com> writes:

> I'm currently developing a DOS based mp3 player (eventually to be used as a
> car stereo), and testing it as I go in a DOS box under Win95. As with most
> developments, my program crashes sometimes (probably a buffer over-run on a
> large array). When the program crashes, it occasionally destroyes the text
> files it happens to have open, either replacing them with a series of
> repeating bytes or blanking them completely. This is strange, since the
> program only ever opens files using the following:
> 
> infile = fopen(filename, "r");
> 
> Note the open mode is "r", for read access only. How can a program crash
> damage files that are never written to, or even open for writing?

If you crash badly enough, you can overwrite the disk cache.  This is
bad, and can cause corruption like you mention.

I don't know if this is what's happening in your case, but it's one
scenario where such a thing might happen.

-- 

Nate Eldredge
neldredge AT hmc DOT edu