Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!ucat!pesnta!amd!intelca!mipos3!pinkas From: pinkas@mipos3.UUCP Newsgroups: comp.sys.ibm.pc Subject: Re: Major bug in all(?) versions of MS-DOS. Message-ID: <432@mipos3.UUCP> Date: Mon, 9-Feb-87 14:23:59 EST Article-I.D.: mipos3.432 Posted: Mon Feb 9 14:23:59 1987 Date-Received: Wed, 11-Feb-87 04:53:17 EST References: <4274@utah-cs.UUCP> Reply-To: pinkas@mipos3.UUCP (Israel Pinkas) Organization: Intel, Santa Clara, CA Lines: 71 Keywords: bug In article <4274@utah-cs.UUCP> b-davis@utah-cs.UUCP (Brad Davis) writes: >; Here is a probable bug (or feature) in MS-DOS. Does anyone know a >; work around (without closing the first file)? Would Gordon Letwin at >; Microsoft care to comment? This bug appears on PC-DOS 2.0, PC-DOS 3.0, >; and MS-DOS 3.1. (Unix has no problems with this algorigthm.) > >; The test goes like this: >; Create a file with name 'xxx'. Call this file FD1. >; Write 80 bytes to FD1. >; Open the file named 'xxx' a second time. Call this file FD2. >; Note that NO errors have happened yet. >; Try to read 80 bytes from FD2. No bytes are read. >; Note that NO error is reported. >; If in symdeb push to a new shell. See that the file 'xxx' has >; been created but has a size of 0. >; Exit the program. See that the file 'xxx' is now 80 bytes long. >; If FD1 is closed at POINT A (see source) then FD2 will perform the read. >; If FD1 is closed at POINT B (see source) then the read of FD2 still fails >; even though the disk has been updated before the read happens. I don't have my DOS manuals in front of me so I'm not sure what the trhee lines of assembly at points A and B are, but here is my explanation of what is happening. When you open file FD1, DOS (and your C compiler) create an internal buffer, usually 128 or 256 bytes long. This buffer is in memory only. The file is created on disk, but the 80 bytes are still in the buffer. Thus, when you open FD2, it can open the file but will return EOF with the first attempt to read. Thus, there is no error reported. Note that with Lattice C (and Turbo Pascal), the input buffer is filled at the time that open is called. Thus, you get an EOF immediately. The call to read() simply copies characters out of the buffer and into the user-supplied memory, refilling the internal buffer as needed. Since EOF was detected when the file was opened, nothing will ever be read. This is the defined and correct behavior for C. If Unix is writing the bytes out to disk before giving the second shell control, it is flushing. To force a file to be written to disk (i.e. make the disk as up to date as possible), use the fflush() routine. My Unix manual entry says (copied without permission, but this is almost identical to every C compiler's endtry on this topic): SYNTAX #include fflush(stream) FILE *stream; DESCRIPTION Fflush causes any buffered data for the named output stream to be written to that file. The stream remains open. I assume whatever C compiler you are using under MS-DOS has a similar call. BTW close() automatically flushes the buffer. Since exit() (called implicitly by falling off the end of main()) calls close() for every file still open, a file might not be written to disk until after the program terminates. (This appears to be happenning in your case.) -Israel P.S. When stating that there is a bug in DOS, please let people know what software you are using when this bug occurs. For example, it would help if I knew what C ompiler you were using. -- ---------------------------------------------------------------------- UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!pinkas ARPA: pinkas%mipos3.intel.com@relay.cs.net CSNET: pinkas%mipos3.intel.com