Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!ucsfcgl!kneller
From: kneller@ucsfcgl.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Major bug in all(?) versions of MS-DOS.
Message-ID: <10056@cgl.ucsf.edu.ucsfcgl.UUCP>
Date: Sat, 7-Feb-87 21:47:49 EST
Article-I.D.: cgl.10056
Posted: Sat Feb  7 21:47:49 1987
Date-Received: Sun, 8-Feb-87 08:31:17 EST
References: <4274@utah-cs.UUCP>
Sender: daemon@ucsfcgl.UUCP
Reply-To: kneller@cgl.ucsf.edu (Don Kneller)
Organization: UCSF Computer Graphics Lab
Lines: 59
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.
Right -- the file exists in the directory entry.  No problem here.

>;	Try to read 80 bytes from FD2.  No bytes are read.
>;		Note that NO error is reported.
What do you mean NO error?  You ask for 80 bytes and read 0.  That says
the read failed.  Read returns the number of bytes read.

>;	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.
File hadn't been closed.  Until it is closed, the size stored in the
directory is *not* the number of bytes written to the file.  Imagine
the disk overhead if the directory was updated each time you wrote to
a file.

>; If FD1 is closed at POINT A (see source) then FD2 will perform the read.
Yes, close the file, the directory entry is updated and the *next* open
will get the file size information from the directory and it will be
correct.

>; 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.
Yes, but the file size is read when the file is opened!  And it was zero then!

[ source deleted ]

The crux of the matter is that the open causes the file size to be read
from the directory entry.  If you have two separate file handles, one
for reading and one for writing, they have separate file pointers.  When
you write to the file with one handle, neither the other file pointer
nor other file size get changed.  (When I say "file pointer", I mean
the number that tells the position in the file in bytes).

If you are simply trying to read and write from the same file, open the
file with read/write access and position the file pointer back to the
beginning of the file with the "lseek" function call (int 21h, ah=42h)
before doing the read.  Then you don't have to close the file before
reading.

One more thing.  If you want to force DOS to update the directory entry
so subsequent opens will work, use "dup" (int 21h, ah=45h) on the file
handle and close the duplicate handle.  Then you won't have to reopen
the file.
-----
	Don Kneller
UUCP:	...ucbvax!ucsfcgl!kneller
ARPA:	kneller@cgl.ucsf.edu
BITNET:	kneller@ucsfcgl.BITNET