On 12 September 2012 10:44, Eric Blake <ebl...@redhat.com> wrote: > On 09/12/2012 08:38 AM, Paul Eggert wrote: >> On 09/12/2012 06:38 AM, Ed Maste wrote: >>> Should ENOTDIR be a permissible errno for this test? >> >> I don't see why. It's not called out in the GNU documentation >> for canonicalize_file_name, and the POSIX documentation for >> realpath does not seem to allow ENOTDIR for the similar >> situation with realpath. Why is the code returning ENOTDIR >> here? > > The POSIX wording is: > > [ENOENT] A component of file_name does not name an existing file or > file_name points to > an empty string. > [ENOTDIR] A component of the path prefix is not a directory, or the > file_name argument > contains at least one non-<slash> character and ends with one > or more trailing > <slash> characters and the last pathname component names an > existing file > that is neither a directory nor a symbolic link to a directory. > > Since '/path/to/zzz' does not exist, this should be ENOENT; ENOTDIR > would only be valid in the case where /path/to/zzz exists but is not a > directory. It sounds like a bug in the FreeBSD kernel. > > That said, are we already replacing realpath() on FreeBSD? If so, then > we should fix our replacement; if not, then I'm probably okay with > relaxing the test to allow the alternate error code.
After a little investigation, I see that the errno comes from FreeBSD's realpath. The behaviour was introduced by the fix for http://www.freebsd.org/cgi/query-pr.cgi?pr=128933 ("realpath(3) does not follow SUS specification for ENOENT / ENOTDIR conditions"), which has a followup with the interpretation that POSIX demands ENOTDIR and provides the following example: # realpath /bin/non_existent/cp realpath: /bin/non_existent/cp: No such file or directory (should be: "Not a directory", as early as non_existent checked) I don't necessarily agree with this interpretation, but I do think there's ambiguity in the POSIX wording. The gnulib test is equivalent to realpath("/path/to/zzz/.."), where it's arguable that a component of the path prefix (specifically, the zzz) is not a directory. -Ed
