bug#29231: 26.0.90; invald file name for symbolic files

[Alan Third]

On Sat, Nov 11, 2017 at 10:54:57AM +0200, Eli Zaretskii wrote:
> This assumes that calling faccessat with an argument "foo/" will
> return zero (i.e. succeed) only if "foo" is a directory, but will fail
> (return non-zero) if it's a file.  I'm guessing that on macOS, this
> call succeeds even for files, or maybe just for symlinks to files.

Only with symlinks faccessat returns success if it’s pointing to a
file and you put ‘/’ on the end. It looks like perhaps adding / to the
end ‘resolves’ symlinks:

    breton:/Users/alan>ls -l cows
    -rw-r--r--  1 alan  staff  0 11 Nov 17:33 cows
    breton:/Users/alan>ls cows/
    ls: cows/: Not a directory
    breton:/Users/alan>ln -s cows moo
    breton:/Users/alan>ls -l moo
    lrwxr-xr-x  1 alan  staff  4 11 Nov 18:14 moo -> cows
    breton:/Users/alan>ls -l moo/
    -rw-r--r--  1 alan  staff  0 11 Nov 17:33 moo/

> Btw, does macOS have faccessat, or does it use the Gnulib replacement?

macOS does have faccessat.

I’m not sure what the fix should be here. The commit introducing this
bug is:

commit 3a8d0cc825635e07da2a90c4ac987b476fc9b05d (HEAD -> emacs-26)
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Mon Jul 31 12:31:02 2017 -0700

    Avoid most stat calls when completing file names

    * admin/merge-gnulib (GNULIB_MODULES): Add d-type.
    * lib/gnulib.mk.in, m4/gnulib-comp.m4: Regenerate.
    * m4/d-type.m4: New file, copied from gnulib.
    * src/dired.c (DT_UNKNOWN, DT_DIR, DT_LINK)
    [!HAVE_STRUCT_DIRENT_D_TYPE]: New constants.
    (dirent_type): New function.
    (file_name_completion): Use it, to avoid unnecessary calls to
    stat-like functions on GNU/Linux and other platforms with d_type.
    (file_name_completion_stat): Just follow the link; there is no
    need to try first with AT_SYMLINK_NOFOLLOW since the directory
    entry was already checked to exist.

Perhaps revert to the old behaviour for Darwin OS?
-- 
Alan Third