Bug 258856 - editors/emacs-devel: Error happens at startup time if ~/.emacs is symbolic link to other file
Summary: editors/emacs-devel: Error happens at startup time if ~/.emacs is symbolic li...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: emacs@FreeBSD.org (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-02 06:52 UTC by Yasuhiro Kimura
Modified: 2021-10-10 10:36 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (emacs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-02 06:52:16 UTC
In my home directory ~/.emacs is symbolic link to ~/.init-files/.emacs

----------------------------------------------------------------------
yasu@rolling-vm-freebsd1[1004]% ls -l ~/.emacs
lrwxr-xr-x  1 yasu  user  18 Jan  6  2015 /home/yasu/.emacs@ -> .init-files/.emacs
yasu@rolling-vm-freebsd1[1005]%
----------------------------------------------------------------------

And after update editors/emacs-devel to ports e7edd97198e4, following error message is displayed in *Warning* buffer when I start emacs.

----------------------------------------------------------------------
Warning (initialization): An error occurred while loading ‘/home/yasu/.emacs’:

Wrong type argument: number-or-marker-p, nil
----------------------------------------------------------------------

The error disappears if I do `rm ~/.emacs; cp ~/.init-files/.emacs ~/.emacs`.

And it only happens with 14-CURRENT.

----------------------------------------------------------------------
yasu@rolling-vm-freebsd1[1007]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct  2 01:34:30 JST 2021     rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
yasu@rolling-vm-freebsd1[1008]%
----------------------------------------------------------------------

With 13.0-RELEASE and 12.2-RELEASE emacs starts without any error.
Comment 1 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-02 10:17:41 UTC
(In reply to Yasuhiro Kimura from comment #0)

Thanks for the report.

Could you share the backtrace from `emacs --debug-init` ? And also could you try with $HOME/.emacs symlinking to an empty file, and see if that generates a warnning too. Essentially, I'm trying to do an equivalent of "emacs -q".

Thanks!
Comment 2 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-02 23:13:50 UTC
(In reply to Ashish SHUKLA from comment #1)

If I start emacs with `--debug-init' option, then following backtrace
is displayed in *Backtrace* buffer.

----------------------------------------------------------------------
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  hack-elisp-shorthands("/home/yasu/.emacs")
  load-with-shorthands-and-code-conversion("/home/yasu/.emacs" "/home/yasu/.emacs" t t)
  load("~/.emacs" noerror nomessage)
  startup--load-user-init-file(#f(compiled-function () #<bytecode -0x17392be6705c7ab>) #f(compiled-function () #<bytecode -0x1f3c686ddc6fc675>) t)
  command-line()
  normal-top-level()
----------------------------------------------------------------------

And the error still happens even if ~/.emacs is symbolic link to empty file.

According to the backtrace I did following test

----------------------------------------------------------------------
yasu@rolling-vm-freebsd1[1092]% cd /tmp
yasu@rolling-vm-freebsd1[1093]% ls -l foo.el bar.el
lrwxr-xr-x  1 yasu  wheel  6 Oct  3 07:56 bar.el@ -> foo.el
-rw-r--r--  1 yasu  wheel  0 Oct  3 07:56 foo.el
yasu@rolling-vm-freebsd1[1094]%
----------------------------------------------------------------------

As you can see /tmp/foo.el is empty file and /tmp/bar.el is symbolic
link to it.

I started emacs with `emacs -Q` and evaluated following 2 s-expressions in  *scratch* buffer.

(hack-elisp-shorthands "/tmp/foo.el")
(hack-elisp-shorthands "/tmp/bar.el")

The former returned nil, and the latter resulted in error with "Wrong type argument: number-or-marker-p, nil".

So it seems the source of problem is `(hack-elisp-shorthands "PATH")` results in error if PATH is symbolic link to normal file.
Comment 3 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-03 02:14:36 UTC
(In reply to Yasuhiro Kimura from comment #2)

`hack-elisp-shorthands` is defined in lisp/international/mule.el as following.

----------------------------------------------------------------------
(defun hack-elisp-shorthands (fullname)
  "Return value of the `elisp-shorthands' file-local variable in FULLNAME.
FULLNAME is the absolute file name of an Elisp .el file which
potentially specifies a file-local value for `elisp-shorthands'.
The Elisp code in FULLNAME isn't read or evaluated in any way, except
for extraction of the buffer-local value of `elisp-shorthands'."
  (let ((size (nth 7 (file-attributes fullname))))
    (with-temp-buffer
      (insert-file-contents fullname nil (max 0 (- size 3000)) size)
      (goto-char (point-max))
      (let* ((found (search-backward-regexp "elisp-shorthands:[ \t]*" 0 t))
             (val (and found
                       (goto-char (match-end 0))
                       (ignore-errors (read (current-buffer)))))
             (probe val)
             aux)
        (catch 'done
          (when (consp probe)
            (while (setq aux (pop probe))
              (unless (and (consp aux)
                           (stringp (car aux))
                           (stringp (cdr aux)))
                (throw 'done nil)))
            val))))))
----------------------------------------------------------------------

In this function `file-attributes` is used to get attributes of file. And the behavior of the function is different between 14-CURRENT and 13.0-REELASE.

As explained before '~/.emacs' is symbolic link to '~/.init-files/.emacs' in my home directory. And if I evaluate '(file-attributes (expand-file-name "~/.emacs"))' on 13.0-RELEASE, I get following result.

----------------------------------------------------------------------
("/home/yasu/.init-files/.emacs" 1 1000 1000 (24921 3099 201298 0) (24921 3099 201298 0) (24921 3099 201298 0) 29 "lrwxr-xr-x" t 471008 250081246980)
----------------------------------------------------------------------

It seems `file-attributes` returns attributes of '~/.emacs' itself (that is, attributes of symbolic link rather than the file it point to).

On the other hand, evaluating the s-expression returns nil on 14-CURRENT. And it results in the error of `hack-elisp-shorthands`.

`find-attributes` is built-in function defined in src/dired.c. But it isn't changed after January 1st of this year.

----------------------------------------------------------------------
yasu@eastasia[2045]% git log -n 1 -- src/dired.c
commit ba05d005e5
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Fri Jan 1 18:13:56 2021

    Update copyright year to 2021
    
    Run "TZ=UTC0 admin/update-copyright".
yasu@eastasia[2045]%
----------------------------------------------------------------------

So it is strange the behavior changed after the update of editors/emacs-devel with ports e7edd97198e4.
Comment 4 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-03 13:47:24 UTC
I tried to reproduce on following host, and unable to:

FreeBSD XXXXXXXXXXXXX 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n246034-e6ab1e365c0: Tue Apr 13 08:54:05 UTC 2021     root@XXXXXXXXXXXXXX:/usr/obj/usr/src/sys/CLUSTER14  amd64

(file-attributes (expand-file-name "~/.emacs")) => ("/home/ashish/.init-files/.emacs" 1 1228 493 (24921 45963 568856 0) (24921 45963 568856 0) (24921 45963 568856 0) 31 "lrwxr-xr-x" t 2643 14263890536310191404)

% ls -la ~/.emacs ~/.init-files/.emacs
lrwxr-xr-x  1 ashish  devel  31 Oct  3 13:43 /home/ashish/.emacs -> /home/ashish/.init-files/.emacs
-rw-r--r--  1 ashish  devel  37 Oct  3 13:38 /home/ashish/.init-files/.emacs


I'll see if I can get a more recent 14-CURRENT host.

Thanks!
Comment 5 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-03 14:43:48 UTC
Could you try the following C program on your 14-CURRENT host ?

-------------------
/* rlnkat.c */

#include <sys/stat.h>

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <strings.h>

#define BUFSIZE 1024

int
main(int argc, char** argv)
{
  int i,ret;
  char buffer[BUFSIZE];
  struct stat st;

  for(i = 1; i < argc; i++) {
    bzero( buffer, sizeof( buffer ));
    ret = fstatat( AT_FDCWD, argv[i], &st, AT_SYMLINK_NOFOLLOW );
    if( -1 == ret ) {
      perror("fstatat");
      continue;
    }
    if( S_ISLNK( st.st_mode )) {
      ret = readlinkat( AT_FDCWD, argv[i], buffer, sizeof( buffer ));
      if( -1 == ret ) {
        perror("readlinkat");
      } else {
        fprintf(stderr, "%d. %s symlink to %s\n", i, argv[i], buffer );
      }
    } else {
      fprintf( stderr, "%d. %s (is directory: %d)\n", i, argv[i], S_ISDIR( st.st_mode));
    }
  }
  return 0;
}
------------------------------------

With following filesystem contents:

lrwxr-xr-x  1 ashish  devel    31B Oct  3 13:43 .emacs -> /home/ashish/.init-files/.emacs
drwxr-xr-x  2 ashish  devel     3B Oct  3 13:43 .init-files
-rw-r--r--  1 ashish  devel    37B Oct  3 13:38 .init-files/.emacs

It results in:

% cc -o rlnkat rlnkat.c

% ./rlnkat .emacs .init-files/.emacs .init-files
1. .emacs symlink to /home/ashish/.init-files/.emacs
2. .init-files/.emacs (is directory: 0)
3. .init-files (is directory: 1)


Could you share output from your side ? This is to rule out any kernel-space changes.

Thanks!
Comment 6 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-05 01:32:56 UTC
(In reply to Ashish SHUKLA from comment #5)

I got following result.

----------------------------------------------------------------------
yasu@rolling-vm-freebsd1[1038]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct  2 01:34:30 JST 2021     rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
yasu@rolling-vm-freebsd1[1039]% cc -o rlncat rlncat.c
yasu@rolling-vm-freebsd1[1040]% ls -ld ~/.emacs ~/.init-files ~/.init-files/.emacs
lrwxr-xr-x  1 yasu  user    29 10月  3 10:49 /home/yasu/.emacs@ -> /home/yasu/.init-files/.emacs
drwxr-xr-x  7 yasu  user    20 10月  2 13:23 /home/yasu/.init-files/
-rw-r--r--  1 yasu  user  4838 10月  2 13:23 /home/yasu/.init-files/.emacs
yasu@rolling-vm-freebsd1[1041]% ./rlncat ~/.emacs ~/.init-files ~/.init-files/.emacs
1. /home/yasu/.emacs symlink to /home/yasu/.init-files/.emacs
2. /home/yasu/.init-files (is directory: 1)
3. /home/yasu/.init-files/.emacs (is directory: 0)
yasu@rolling-vm-freebsd1[1042]% 
----------------------------------------------------------------------

I created 14-CURRENT amd64 main-n246034-e6ab1e365c environment and confirmed Emacs 29.0.50.20211001 starts without any error. So I'll do `git bisect` with /usr/src to decide when the error starts happening.
Comment 7 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-05 06:24:41 UTC
(In reply to Yasuhiro Kimura from comment #6)

Before starting `git bisect` I updated host system from main-n246034-e6ab1e365c to main-n249811-a36230f75e0 and checked if emacs binary built on the former result in error if it is executed on the latter. Then emacs starts without error.

Next I rebuilt all packages on main-n249811-a36230f75e0 and reinstalled them. Naturally error happened when I started Emacs.

And finaly I reverted host system to main-n246034-e6ab1e365c and checked what happens if I executed emacs binary build on main-n249811-a36230f75e0. Then following message is displayed in *Warnings* buffer.

----------------------------------------------------------------------
Warning (initialization): An error occurred while loading `/home/yasu/.emacs':

File error: Getting attributes, Too many links, /home/yasu/.emacs
----------------------------------------------------------------------

So it seems the source of the problem exists in not kernel but userland.
Comment 8 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-05 17:30:56 UTC
Hi Kimura-san!

Thanks for debugging. That's very helpful.

Could you try this on your problematic installation ?


  $ truss -s 500 -f emacs --eval '(kill-emacs)' 2>/tmp/emacs.err

And attach the /tmp/emacs.err to this bug report, or you can investigate yourself by grep-ing for the error message in the file, and then checking to see if there are any failed syscalls around that, which can shed some light on this ? My guess is likely not, as you mention that it's a userspace problem.

Thanks!
Comment 9 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-05 17:37:09 UTC
Could you also share the output of, from the problematic system:

  $ pkg info editors/emacs-devel |sed -n -e '/^Options/,/^[^[:space:]]/p'

Or:

  $ make -C /usr/ports/editors/emacs-devel showconfig

Thanks!
Comment 10 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-05 18:45:50 UTC
Hi Kimura-san!

I think I figured it out.

Could you please compile following program on problematic system:

=======================
/* rlnkat2.c */

#include <sys/stat.h>

#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <strings.h>

#define BUFSIZE 1024

int
main(int argc, char** argv)
{
  int i,ret;
  char buffer[BUFSIZE];
  struct stat st;
  int fd;
  
  for(i = 1; i < argc; i++) {
    bzero( buffer, sizeof( buffer ));
    fd = AT_FDCWD;
    ret = EINVAL;
#ifdef O_PATH
    fprintf( stderr, "Trying openat(%s): ", argv[i]);
    ret = openat( fd, argv[i], O_PATH | O_CLOEXEC | O_NOFOLLOW, 0);
    if( -1 == ret ) {
      ret = errno;
      perror("openat");
    } else {
      fprintf( stderr, "%d\n", ret );
      if( 0 != fstat( ret, &st )) {
	ret = errno;
	fprintf( stderr, "fstat(%s): errno: %d, %s\n", argv[i], errno, strerror(errno)); 
      } else {
	fd = ret;
	ret = 0;
      };
    }
#endif
    if( EINVAL == ret ) {
      ret = fstatat( fd, argv[i], &st, AT_SYMLINK_NOFOLLOW );
    }
    if( -1 == ret ) {
      perror("fstatat");
      continue;
    }
    if( S_ISLNK( st.st_mode )) {
      ret = readlinkat( fd, argv[i], buffer, sizeof( buffer ));
      if( -1 == ret ) {
	perror("readlinkat");
      } else {
	fprintf(stderr, "%d. %s symlink to %s\n", i, argv[i], buffer );
      }
    } else {
      fprintf( stderr, "%d. %s (is directory: %d)\n", i, argv[i], S_ISDIR( st.st_mode));
    }
  }
  return 0;
}
=================



% cc -o rlnkat rlnkat.c

% ./rlnkat .emacs .init-files/.emacs .init-files

My guess is O_PATH is defined in 14-CURRENT[0], which enables openat(), which is passed a symlink as parameter with O_NOFOLLOW.

========== excerpt from open(2): 
     [EMLINK]           O_NOFOLLOW was specified and the target is a symbolic
                        link.
==========

So the culprit is openat but it only gets enabled/compiled on a system which has O_PATH defined in its headers (which only happened after that particular revision[0]).

If this is indeed the case, then as per man page of open(2)[1] from GNU/Linux:

=========
       ELOOP  Too many symbolic links were encountered in resolving pathname.
  
       ELOOP  pathname was a symbolic link, and flags specified O_NOFOLLOW but not O_PATH.
=========

it seems like a bug in FreeBSD implement, as GNU Emacs seems to be passing O_PATH along with O_NOFOLLOW which should not cause this EMLINK error.

Anyways, this is all a speculation, so please let us know the output. And thank you for trying various things. 

References:

[0] https://cgit.freebsd.org/src/commit/?id=8d9ed174f3afba5f114742447e622fc1173d4774

[1] https://www.man7.org/linux/man-pages/man2/open.2.html

Good night!
Comment 11 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-06 05:28:18 UTC
(In reply to Ashish SHUKLA from comment #10)

I got following result.

----------------------------------------------------------------------
yasu@rolling-vm-freebsd1[1064]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct  2 01:34:30 JST 2021     rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
yasu@rolling-vm-freebsd1[1065]% make
cc  -O2 -pipe -c rlnkat.c -o rlnkat.o
cc -o rlnkat rlnkat.o
cc  -O2 -pipe -c rlnkat2.c -o rlnkat2.o
cc -o rlnkat2 rlnkat2.o
yasu@rolling-vm-freebsd1[1066]% ls -ld ~/.emacs ~/.init-files ~/.init-files/.emacs
lrwxr-xr-x  1 yasu  user    29 10月  3 10:49 /home/yasu/.emacs@ -> /home/yasu/.init-files/.emacs
drwxr-xr-x  7 yasu  user    20 10月  2 13:23 /home/yasu/.init-files/
-rw-r--r--  1 yasu  user  4838 10月  2 13:23 /home/yasu/.init-files/.emacs
yasu@rolling-vm-freebsd1[1067]% ./rlnkat2 ~/.emacs ~/.init-files ~/.init-files/.emacs
Trying openat(/home/yasu/.emacs): 3
1. /home/yasu/.emacs symlink to /home/yasu/.init-files/.emacs
Trying openat(/home/yasu/.init-files): 4
2. /home/yasu/.init-files (is directory: 1)
Trying openat(/home/yasu/.init-files/.emacs): 5
3. /home/yasu/.init-files/.emacs (is directory: 0)
yasu@rolling-vm-freebsd1[1068]%
----------------------------------------------------------------------
Comment 12 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-06 06:23:24 UTC
(In reply to Yasuhiro Kimura from comment #11)

What if you run rlnkat on this system "main-n246034-e6ab1e365c" ?

Thank you!
Comment 13 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-06 06:36:58 UTC
(In reply to Ashish SHUKLA from comment #8)

Also were you able to try this `truss` ?

As far as I can tell, there are two problems, 1) where `find-attributes` returned "Too many links" error (main-n246034-e6ab1e365c), and 2) where it returned nil (main-n249811-a36230f75e0).

Thanks in advance
Comment 14 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-06 17:00:31 UTC
(In reply to Ashish SHUKLA from comment #12)

----------------------------------------------------------------------
yasu@rolling-vm-freebsd4[1005]% uname -a
FreeBSD rolling-vm-freebsd4.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n246034-e6ab1e365c0: Tue Oct  5 04:34:51 JST 2021     rootz@rolling-vm-freebsd4.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
yasu@rolling-vm-freebsd4[1006]% make
cc  -O2 -pipe -c rlnkat.c -o rlnkat.o
cc -o rlnkat rlnkat.o
cc  -O2 -pipe -c rlnkat2.c -o rlnkat2.o
cc -o rlnkat2 rlnkat2.o
yasu@rolling-vm-freebsd4[1007]% ls -ld ~/.emacs ~/.init-files ~/.init-files/.emacs
lrwxr-xr-x  1 yasu  user    29 10月  3 10:49 /home/yasu/.emacs@ -> /home/yasu/.init-files/.emacs
drwxr-xr-x  7 yasu  user    20 10月  2 13:23 /home/yasu/.init-files/
-rw-r--r--  1 yasu  user  4838 10月  2 13:23 /home/yasu/.init-files/.emacs
yasu@rolling-vm-freebsd4[1008]% ./rlnkat ~/.emacs ~/.init-files ~/.init-files/.emacs
1. /home/yasu/.emacs symlink to /home/yasu/.init-files/.emacs
2. /home/yasu/.init-files (is directory: 1)
3. /home/yasu/.init-files/.emacs (is directory: 0)
yasu@rolling-vm-freebsd4[1009]%
----------------------------------------------------------------------
Comment 15 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-06 17:11:25 UTC
(In reply to Ashish SHUKLA from comment #13)

Result of `truss -s 500 -f emacs --eval '(kill-emacs)' 2>/tmp/emacs.err` on main-n249811-a36230f75e0.

https://www.utahime.org/FreeBSD/main-n249811-a36230f75e0.emacs.err

And result of `pkg info editors/emacs-devel |sed -n -e '/^Options/,/^[^[:space:]]/p'`  on main-n249811-a36230f75e0.

----------------------------------------------------------------------
yasu@rolling-vm-freebsd1[1038]% uname -a
FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n249811-a36230f75e0: Sat Oct  2 01:34:30 JST 2021     rootz@rolling-vm-freebsd1.home.utahime.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
yasu@rolling-vm-freebsd1[1038]% pkg info editors/emacs-devel |sed -n -e '/^Options/,/^[^[:space:]]/p'
Options        :
        ACL            : on
        GNUTLS         : on
        JSON           : on
        KQUEUE         : on
        MAILUTILS      : off
        MODULES        : on
        NATIVECOMP     : on
        SOURCES        : on
        THREADS        : on
        XML            : on
Shared Libs required:
yasu@rolling-vm-freebsd1[1039]% 
----------------------------------------------------------------------

But I confirmed the problem still happens if I disabled NATIVECOMP option.
Comment 16 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-07 03:10:12 UTC
(In reply to Yasuhiro Kimura from comment #15)

Hi Kimura-san!


Following excerpt from truss output looks interesting:

---------
 3037: read(5,";;; -*- Mode: emacs-lisp -*-\n;;;\n;;; Startup file for GNU Emacs\n\n;;;\n;;; OS\M-g\M^R\M-0\M-e\M-"\M^C\M-c\M^A\M-.\M-f\M-$\M^\\M-e\M^G\M-:\n;;;\n(cond ((eq system-type 'gnu/linux)\n       (setq utahime:os-name\n\t     (substring (shell-command-to-stri
 3037: lseek(5,0x0,SEEK_SET)                     = 0 (0x0)
 3037: close(5)                                  = 0 (0x0)
 3037: openat(AT_FDCWD,"/home/yasu/.emacs",O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH,00) = 5 (0x5)
 3037: fstat(5,{ mode=lrwxr-xr-x ,inode=471008,size=29,blksize=4096 }) = 0 (0x0)
 3037: readlinkat(5,"",0x7fffffffd090,1024)      ERR#2 'No such file or directory'
 3037: close(5)                                  = 0 (0x0)
---------

Compared to following output on my GNU/Linux host:

---------
openat(AT_FDCWD, ".emacs", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3
newfstatat(3, "", {st_mode=S_IFLNK|0777, st_size=15, ...}, AT_EMPTY_PATH) = 0
readlinkat(3, "", ".emacs.d/.emacs", 1024) = 15
---------

---------
lrwxrwxrwx abbe users 15 B Thu Oct  7 08:09:27 2021  .emacs ⇒ .emacs.d/.emacs
---------

Esp. the readlinkat() syscall invocation where it returns ENOENT (on FreeBSD), compared to GNU/Linux where it returns the symlink target.

I'm trying to get access to a recent 14-CURRENT host, where I can verify this. It'll take me some time.

Thank you for providing outputs so far.

And thanks in advance for patience.
Comment 17 Yasuhiro Kimura freebsd_committer freebsd_triage 2021-10-07 14:33:18 UTC
(In reply to Ashish SHUKLA from comment #16)

It took for a while but `git bisect` finished. And according to it the
problem happens with base 8d9ed174f3a or later.

----------------------------------------------------------------------
commit 8d9ed174f3a
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:   Thu Mar 18 19:41:47 2021

    open(2): Implement O_PATH
    
    Reviewed by:    markj
    Tested by:      pho
    Discussed with: walker.aj325_gmail.com, wulf
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week
    Differential revision:  https://reviews.freebsd.org/D29323
----------------------------------------------------------------------

Is it consistent with the result of your investigation?
Comment 18 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-08 19:38:12 UTC
(In reply to Yasuhiro Kimura from comment #17)

Hi Kimura-san!

As I mentioned in comment #10, it's indeed that commit base 8d9ed174f3, which caused O_PATH pre-processor conditional block (in dired.c) to become active and take that path, and as readlinkat does not seem to exhibit same behaviour as GNU/Linux (which is what likely that Emacs code was implemented on), it breaks Emacs' assumption. I've yet to verify it myself due to lack of corresponding 14-CURRENT host, but your bisection confirms it.

I'll get back to you with next steps.

Thanks for your help so far.
Comment 19 commit-hook freebsd_committer freebsd_triage 2021-10-09 19:33:02 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=5fb54d2fc845464ea809e6a1a69380693943cf51

commit 5fb54d2fc845464ea809e6a1a69380693943cf51
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2021-10-09 05:12:05 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2021-10-09 19:31:37 +0000

    readlinkat(2): allow O_PATH fd

    PR:     258856
    Reported by:    ashish
    Reviewed by:    markj
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week
    Differential revision:  https://reviews.freebsd.org/D32390

 lib/libc/sys/open.2     | 5 +++--
 sys/kern/vfs_syscalls.c | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)
Comment 20 commit-hook freebsd_committer freebsd_triage 2021-10-10 09:25:15 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=156db355733241fc1fd824fd8b1ce9f6f7f5f30a

commit 156db355733241fc1fd824fd8b1ce9f6f7f5f30a
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2021-10-09 05:12:05 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2021-10-10 09:22:58 +0000

    readlinkat(2): allow O_PATH fd

    PR:     258856

    (cherry picked from commit 5fb54d2fc845464ea809e6a1a69380693943cf51)

 lib/libc/sys/open.2     | 5 +++--
 sys/kern/vfs_syscalls.c | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)
Comment 21 Ashish SHUKLA freebsd_committer freebsd_triage 2021-10-10 10:36:17 UTC
Marking as closed, as it is not reproducible for me anymore after the proposed change.

Please re-open it, if it's still not resolved for you.