Re: readdir(3): behavior on descriptors with O_SEARCH

[Dmitry Selyutin <ghostman.sd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

I think the mistery is partially solved: glibc simply doesn't have
O_SEARCH, so the following code

#ifdef O_SEARCH
flags |= O_SEARCH
#endif

does not execute (so only O_DIRECTORY is being set). Dumb, had to check
twice, sorry for the noise.

However, the question if it is correct to define O_SEARCH to be equal to
O_PATH. From what I see, both O_SEARCH and O_EXEC have the same value as
O_PATH, but I'm not sure if this solution is technically correct.

However, I suspect that support for O_EXEC and O_SEARCH must be provided by
the kernel first, so until kernel implements such functionality, all talks
seem to be meaningless (unless someone wants to emulate such functionality
in the userspace). Anyway, I tend to think that any attempt to use O_SEARCH
until then should either return -1 on open(3), or NULL on fdopendir(3); I
really don't think that O_SEARCH shall mean the same as O_PATH.

But I'm by no means claim myself to be a POSIX expert; what do you think?
The information on O_SEARCH seems to be incomplete and even inconsistent,
so it may turn that my claims are incorrect. Any suggestions are welcome;
I'll take a more deep look at it in the evening.

And again, thank you for your help!

[-- Attachment #2: Type: text/html, Size: 1355 bytes --]