2019-07-30 11:27:15 +0100, Geoff Clare: [...] > > 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 inconsistent with your position on ENOTDIR. > > If regfile exists then you claim regfile/*.c isn't going to produce any > matches, so it should be ignored. Likewise if brokensymlink exists > then brokensymlink/*.c isn't goint to produce any matches so to be > consistent you should also want that to be ignored. [...]
But in long/path/with/spaghetty/symlinks/*/*.c, the fact that an extra symlink brings you over the limit (of number of links for ELOOP or of path length for ENAMETOOLONG) prevents you from listing that directory for a reason that is worth reporting IMO. While there's no doubt in my mind that asking glob() to report ENOTDIR errors in */*.c is wrong. That would be like asking that ls -LR or find -L report them as well (ls -LR reports a ENOTDIR error when a non-directory/file is passed as argument or is found in the target of a symlink, but obviously not for the non-directory files it finds by reading a directory, maybe that can be adapted for glob()). I don't think there's an ideal way to deal with it. That interface is already broken/misdesigned in that it reports the EACCESS errors in */*.c and not */file. Not reporting the ENOTDIR error is definitely an improvement, at least in the case of opening a directory that results from wildcard expansion (one could argue glob() shouldn't try to open it in the first place), not sure about ENOENT/ELOOP/ENAMETOOLONG. Do you have a better suggestion? -- Stephane
