From: Alan Third <alan@idiocy.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Vincent Zhang <vincent_chueng@hotmail.com>,
Paul Eggert <eggert@cs.ucla.edu>,
29231@debbugs.gnu.org
Subject: bug#29231: 26.0.90; invald file name for symbolic files
Date: Sat, 11 Nov 2017 18:25:20 +0000 [thread overview]
Message-ID: <20171111182520.GA5075@breton.holly.idiocy.org> (raw)
In-Reply-To: <837euxp53y.fsf@gnu.org>
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
next prev parent reply other threads:[~2017-11-11 18:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 17:41 bug#29231: 26.0.90; invald file name for symbolic files Vincent Zhang
2017-11-09 20:17 ` Eli Zaretskii
2017-11-10 2:49 ` Vincent Zhang
2017-11-10 8:13 ` Eli Zaretskii
2017-11-10 10:10 ` Vincent Zhang
2017-11-11 8:54 ` Eli Zaretskii
2017-11-11 18:25 ` Alan Third [this message]
2017-11-11 19:00 ` Eli Zaretskii
2017-11-11 23:21 ` Paul Eggert
2017-11-12 7:19 ` Paul Eggert
2017-11-12 12:09 ` Alan Third
2017-11-13 2:53 ` Vincent Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171111182520.GA5075@breton.holly.idiocy.org \
--to=alan@idiocy.org \
--cc=29231@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=vincent_chueng@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).