Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!THESS@dec-marlboro
From: THESS%dec-marlboro@sri-unix.UUCP
Newsgroups: net.micro.cpm
Subject: Re: Function 37
Message-ID: <15594@sri-arpa.UUCP>
Date: Mon, 16-Jan-84 20:52:00 EST
Article-I.D.: sri-arpa.15594
Posted: Mon Jan 16 20:52:00 1984
Date-Received: Thu, 19-Jan-84 01:13:06 EST
Lines: 30

From:  "Ted Hess" <THESS@dec-marlboro>

Folks - CP/M-80 & CP/M-86 will read a directory whenever:

1) You open a file

2) Close a file

3) Do a directory operation like delete, rename etc...

4) The first disk i/o performed (on each drive) after "warm boot","disk reset",
   or ^C (which causes warm boot).

5) Every time you do I/O to a file across a 16K boundary (ie 16K := 1 extent).
   NOTE: No matter what block size or disk organization you use, this is one of
   CP/M's natural (and most inefficient) constants.

Oh yes, CCP/M gets around this by using an LRU disk cache and expecting
the BIOS to inform it that a drive door changed state. The unfortunate
fact about this feature is that it is very difficult to flush these
buffers from inside an application. It seems that CCP/M won't flush the
buffers and mark them invalid if there are any files open on that drive.
The problem, I suppose is to prevent a disk change while a file is open,
however, I don't think anything is being gained by preventing an
application from trying to guarantee all the data it has modified
(including the directory itself), be up to date!

Sorry, didn't mean to flame CCP/M - It's really quite nice.
					/ted
   --------