Robert Elz via austin-group-l at The Open Group wrote in
<9252.1598969...@jinx.noi.kre.to>:
| Date: Tue, 1 Sep 2020 10:32:55 +0100
| From: "Geoff Clare via austin-group-l at The Open Group" \
| <austin-group-l@opengroup.org>
| Message-ID: <20200901093255.GA7629@localhost>
|
|| but I'm not sure how useful this would be to applications. In any case
|| it would be highly unusual for an application to use such a small buffer.
|
|I would suggest that we stop worrying about telling applications how
|to write code to use the interfaces, or at least until the interface is
|properly specified.
But the interfaces are decades old, isn't that wording too strong?
if(_impl->cast.ui1p < _impl->maxcast || a_FillBuffer(_impl)) {
de = _impl->cast.dep;
_impl->cast.ui1p += de->d_reclen;
} else
de = NIL;
This code worked two decades ago, and it would be great if it
would still work in two decades from now on.
_impl->cast.ui1p = _impl->buffer;
_impl->maxcast = _impl->buffer + u.osret;
where u.osret is "what posix_getdents()" returned (positively).
|What's more important is what happens if the application buffer isn't
|big enough for the next entry. What do the existing getdents()
|implementations do in that case? If they're all the same then
|posix_getdent() should do the same thing (EINVAL? E2BIG?) - if they
|differ, then we can decide what's best.
Isn't that covered nicely by the posted text? There must be space
for at least one entry, otherwise EINVAL occurs? And upon success
"a non-negative integer shall be returned indicating the number of
bytes occupied by the <b>posix_dent</b> structures placed in
<i>buf</i>", which even for a non-native tongue implies that there
may be pad left. I think you are overcomplicating here.
|Similarly for what is done for directory pieces that don't contain
|files, on filesystems that allow that (inode number == 0 or perhaps
|a file type for "dummy entry" or something, or whatever).
I personally would say that these should be skipped. The data is
copied over to user buffers, and these entries are simply not
copied. That seems to be the best. The Group does not seem to
want to add DT_WHITEOUT or similar things.
With directory entries you always have races, as you of course
surely know, so any data you see can anyway only be an indication,
the standard itself talks about races regarding this (and
introduced the "at" series to overcome some of them).
|Do the existing implementations ever return such things? Do they
I personally have not seen it, but this likely is a very
filesystem dependent thing, which possibly even changes over time.
|hide them by making the reclen of the previous entry (if there is
|one in the buffer) bigger, or do they squash them out, moving the
|next existing entry down to follow immediately after the previous one
|(where all the reclen's are as small as possible to contain the
|sctuct header, the name (and its \0) and alignment padding.) This is
|a case where we don't necessarily need to specify one scheme that
|must be used - we can leave that for the implementation, as long as
|applications are informed what might happen.
The proposed text says that filenames are NUL terminated and
hopping from entry to entry happens by adding the reclen to the
current entry (casted to char*). So it seems there could be data
in between. Empty names are not allowed, so this. As some
getdent implementations used to use d_ino fields, others d_fileno,
it may be necessary anyway to create a very small posix_getdents()
system call wrapper, one which boils down the huge number of
filesystem informations to what posix_dent actually serves?
|If after all of this (and perhaps more) is worked out, if there is
|an example application fragment that can usefully be included to
|demonstrate how the interface might be used, then fine - but this
|is a bonus extra, not really required in the standard.
It is wonderful you say this, having a way to directly read
directory content into buffers without having to use these other
functions, which may perform memory allocations which may impose
locking noise etc etc, and getting the d_type field directly as
well, and you know _how_ terribly it was to write that code in the
past, where you possibly even had to have valid path names around
in order to stat(2) a directory entry, at least for the
theoretical case that d_type does not exist!
Thanks,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
