Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!houxm!homxb!gemini
From: gemini@homxb.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Major bug in all(?) versions of MS-DOS.
Message-ID: <2368@homxb.UUCP>
Date: Sun, 8-Feb-87 15:59:02 EST
Article-I.D.: homxb.2368
Posted: Sun Feb  8 15:59:02 1987
Date-Received: Tue, 10-Feb-87 01:39:20 EST
References: <4274@utah-cs.UUCP> <10056@cgl.ucsf.edu.ucsfcgl.UUCP>
Organization: PC Research, Inc.
Lines: 18
Keywords: bug
Summary: bug or misfeature

All this brew-ha-ha about what is either a DOS bug, or a DOS
shortcoming.

In article <10056@cgl.ucsf.edu.ucsfcgl.UUCP>, kneller@socrates.ucsf.edu (Don Kneller%Langridge) writes:
> 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.

No overhead, the directory is (should) be in a buffer, too.  Note that
UNIX does exactly this (actually updates the inode, not the directory).
Otherwise, commands like "tail -f" wouldn't work.  I'm tempted to
call this DOS behavior a bug although it could be a (mis)feature if it is
documented.  It will certainly be called a bug when multiprocessing
DOS arrives (if ever).

Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP
..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.