Re: encapsulating directory operations

On 20.05.2025 08:06, Paul Edwards wrote:

Someone (Jean-Marc) wrote some "folder" routines which I like a lot.
You can see them here:
 
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/hwzip/folder.c
 
And in essence, when you read from a directory, the only
thing you get is the filename. If it is actually a subdirectory,
then that is indicated with a "/" at the end of the filename.
 
Other things like size and creation date are not available,
and C90 does not guarantee that such concepts even
exist. C90 does guarantee that files exist though.
 
And in fact, files are the only thing that are ever actually
externally visible to a C90-compliant program.
 
Now it so happens that I need to traverse directories.
I want this to run on MVS/TSO as well as other environments,
and I have a way of making directories appear, even though
they don't really exist on the mainframe (traditional, like
MVS 3.8J).
 
So they will appear to be an 8.8 files, simlar to traditional
8.3 with FAT.
 
Plus I want to work with modern FAT long filenames, and
Unix too.
 
The folder routines will do everything I need.
 
The mkfldr() routine won't work under my MVS/TSO design,
but that doesn't bother me. I can probably make rmfldr() work,
but don't intend to for now.
 
Now C90 doesn't have folder/directory operations (such as
opendir()) for a reason.
 
That reason may cease to exist if I can demonstrate directories
grafted onto the mainframe.
 
And C90 (etc) could potentially be extended to include a folder.h
 
Or this could be something that doesn't belong in the C standard.
 
Or alternatively, this could be something incorporated within the
C90 standard, as designed.
 
I have already demonstrated zmodem working on a COM1
stream opened with fopen (shipped with Freewindows at
pdos.org). Interesting note is that I needed to escape the
MSDOS x'1a' (EOF) because something was swallowing it.
And I demonstrated it via my mainframe emulator too - giving
the mainframe the ability to connect to a BBS and do a FREQ.
Should work on real hardware too, using a TN3270 OSA/ICC
as an encapsulation layer, as I previously demonstrated with
an EBCDIC ANSI terminal.
 
So the next thing that I would potentially encapsulate is
something like this:
 
fopen(argv[1], "w+");
 
where the argument might be "/some/dir/" (with a terminating /
for good measure).
 
And then do a fputs("dir\n");
 
And fgets() and collect each name from the folder, using something
similar to those folder routines above - all done internally so not
really relevant.
 
Possibly a rewind() to reset the EOF condition of  the fgets.
Or maybe an fseek to offset 0 from SEEK_CUR.
 
And fputs("mkdir subdir\n"); to make a subdirectory.
 
And fputs("rmdir subdir\n"); to remove one.
 
And fputs("cd ..\n"); to change directory.
 
 
I'm wondering what the underlying principles here are that
would govern the correct thing to do.
 
Maybe I shouldn't be overloading the FILE concept to make
an artificial file.
 
Or maybe it is the other way around - we should perhaps
eliminate lots of APIs - like the TCP/IP ones - and stick
them all inside streams, and perhaps FILE is a misnomer,
it should have really been called STREAM.
 
Any thoughts (besides "get a life!")?

Directories are like files entities that have to and are handled
by the OS. Different OSes provide different interfaces to those
functions. There's, for example, Unix systems that historically
had differing interfaces. So standards have evolved (SUS, POSIX)
to get a common interface for Unix systems. Those standards also
define (besides the system calls) the other types of interfaces;
the shell and the Unix utilities called from the shell. Besides
the system calls (that are "incidentally" written and documented
in the C language) there's the languages that may want their own
abstractions; e.g. 'printf' (vs. 'write'). Such abstractions are
certainly useful to be supported as library functions. And I'd
write and provide directory abstractions also as add-on library
functions (as opposed to part of a language; but my opinion on
that is not strong). Historically other languages even missed to
provide any I/O functions; vendors provided own (non-standard)
functions. This had been considered a bad decision. There's also
other abstractions to files and directories, like, e.g. the OSI
and ITU-T standards for directories (X.500) and for file access
and management (FTAM); both abstracted on the upper OSI layer 7.

To sum up; on the way from the OS entity to the user interface
there's various abstraction levels. Depending on the service I'd
like to provide I'd probably choose different abstraction layers.
I _don't_ think that a directory abstraction should be *inherent*
part of the C language, but if necessary provided as a _library_.

Just my opinion on (some of?) your questions. HTH.

Janis

 
Thanks. Paul.