🚀 go-pugleaf

>	The ANSI C standard seems to have a rather odd mix of file 
>operations.  Why didn't they add (over K&R) some other useful file 
>operations such as fileexist, getfirst, getnext, etc?  It seems that 
>these could not be much more dependent on the underlying file system than 
>rename or remove.

It is not the job of standards committees to invent a lot of new
functions.  There have been many complaints that the committee went
too far with inventing things already.

Adding directory-reading interfaces to ANSI C brings up many issues which
ANSI C would be better off trying not to nail down.  

A getfirst/getnext interface (which I assume refers to the CP/M
directory-reading calls which later made their way into MSDOS)
is irritating, because of the contortions needed to loop over all
files, treating the first call specially.  One of the really
irritating problems in CP/M, which may have made its way into MSDOS,
is that there was no documented way to get or restore the "next directory 
entry pointer" (except to the beginning), and further, other file 
operations like creating, deleting, or opening files messed up that
hidden variable.

But there's a worse problem.  What do the terms "first" and "next" 
mean, given that the program is doing things to the directory during 
a scan?  Even an opendir()/readdir()/closedir() interface has
this problem.

What should the following loop do?  Assume you've got a function
called readdirname() which returns the names (strings) of files
in a directory on successive calls, and returns NULL when it
reaches the end.

	char	*fn;

	opendirname(name);
	while ((fn = readdirname()) != NULL)
		remove(fn);

Does this delete ALL the files?  That assumes that the directory stays
in the same order (except for the file being deleted) during a
remove().  Directories that are maintained sorted, use hashing, or
do automatic compaction either make it impossible to implement
readddirname() on top of the existing OS, or end up skipping files.
Some versions of VMS, at least, had some problems with this. 
The issue gets even more confusing if you throw in another process
that repeatedly creates and deletes "x.tmp".  Does this cause the
loop above to skip some entries OTHER THAN "x.tmp"?

					Gordon L. Burditt
					sneaky.lonestar.org!gordon