Re: encapsulating directory operations

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
news:100j5lr$2fqhj$3@dont-email.me...

On Tue, 20 May 2025 19:33:18 +1000, Paul Edwards wrote:
>

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
news:100hase$24odp$1@dont-email.me...

>
On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote:
>

And in essence, when you read from a directory, the only thing you
get is the filename.

>
You want at least the type of entry as well, surely.
>
<https://manpages.debian.org/readdir(3)>

>
No - I'm not attempting to support such sophistication.

>
It's not about sophistication, it's about efficiency in real-world
operation. Without that, you will need to do a second lookup in nearly
every common directory-traversal case.

Your definition of "real world", is probably "not C90".

My goal is to support C90 - or close - not "real world".

C90 currently doesn't support directories AT ALL. Neither
efficient nor inefficient.

I'm talking about changing that.

Your "real world" applications won't work on traditional MVS,
so the features you are trying to make work simply won't work.
Neither efficient nor inefficient. They won't work. The "real
world" directories you imagine are not universal.

However, a somewhat kludged directory system is probably
universal.

You probably can write a portable app that does directory
traversal.

Portable - including to a mainframe.

You won't be able to do a mkdir() though.

Making a directory is a lot of work.

You need to decide what filetypes you want to support.
Your files will all need to have extensions (same as CMS
requires). And you will need to decide how much space
you want for each file type. And you will also need to
decide what RECFM you want, and thus what the longest
line in a text file will be.

You could potentially go for RECFM=U to avoid that
issue, but that will be up to the installation.

And then you will have done what other people can do
with a mkdir() call.

ie the C90+ standard will mention "mkdir" may not
work (implementation-defined). And a portable app
should not call mkdir().

But the other operations - except possibly rmdir(), can
be made to work, I believe. So that is the level where
you can write portable programs.

So you can write a zip program, but not an unzip program,
unless you restrict unzip with "-j".

Or, there is a way around that. You can do a mkdir()
outside of your app, and then allow your app to proceed,
even if mkdir() returns with "directory already exists".

Access time, inode, file size? Forget about it. Not
portable.

If it is actually a subdirectory, then that is indicated with a "/"
at the end of the filename.

>
What if it's a symlink to a directory?

>
I guess that can be left as "implementation-defined". I would treat it
the same as a hardlink, ie a directory.

>
The key point about symlinks is they are not the same as hardlinks.

There is no such universal concept for either of those things,
so outside the remit of both C90 and C90+.

BFN. Paul.