2019-07-30 10:48:49 +0100, Geoff Clare: [...] > The odd thing about all these implementations that ignore ENOTDIR and ENOENT > (or don't but think they should), is that they are not following either of > the possible interpretations of the current text. > > If they want to interpret it literally and only report an error when they > encounter an existing directory that they can't open, then they should not > just ignore ENOTDIR and ENOENT from opendir(), they should also ignore > ELOOP and ENAMETOOLONG. [...]
Note that there's only one implementation (that I found) that ignores ENOENT: FreeBSD (also found on macOS). ENOTDIR was added to glibc/gnulib/uclibc/dietlibc because of */*.c returning an error on non-directory files in the current directory which is a common, normal case where we don't want an error to be reported. While ELOOP and ENAMETOOLONG are pathological case which as you said in a related discussion could be worth reporting. For ENOENT, that can be seen as a pathological case worth reporting as well, especially in the */*.c case where the current directory contains broken symlinks. That's why in my proposed resolution, I left it open whether to specify the GNU or FreeBSD behaviour or allow both. We could make it: - ENOTDIR errors upon opendir() shall be ignored - ENOENT/ENAMETOOLONG/ELOOP may be ignored. Or we could allow all existing implementations and replace that "shall" with a "should" or "may". -- Stephane
