bug#66638: 29.1; `file-relative-name' and symbolic links

bug#66638: 29.1; `file-relative-name' and symbolic links

[Bogdan Ruslanovich Drozd]

How I found the bug: LaTeX previews were not displayed in Org mode
because the path where the file lies contains a symbolic link
(e.g. `/home/user/docs/org' directory where `/home/user/docs' is a
symbolic link to a directory).

Bug description: `file-relative-name' (in `files.el') doesn't take into
account symbolic links.

How to reproduce:

1. Run `mkdir -p ~/a_dir/org'.

2. Run `ln -s ~/a_dir/org ~/docs'.

3. Run `emacs -Q ~/docs/example.org'.

4. Insert into the file "$2+2=4$", press `C-c C-x C-l', and see that it
does not work.

5. Kill emacs.

6. Run `emacs -Q ~/a_dir/org/example.org'.

7. Insert into the file "$2+2=4$, press `C-c C-x C-l', and see LaTeX
preview.

In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
 cairo version 1.17.8) of 2023-09-30 built on localhost
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Gentoo Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --datarootdir=/usr/share
 --disable-silent-rules --docdir=/usr/share/doc/emacs-29.1-r1
 --htmldir=/usr/share/doc/emacs-29.1-r1/html --libdir=/usr/lib64
 --program-suffix=-emacs-29 --includedir=/usr/include/emacs-29
 --infodir=/usr/share/info/emacs-29 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
 --with-native-compilation=aot --with-json --without-kerberos
 --without-kerberos5 --with-lcms2 --with-xml2 --without-mailutils
 --without-selinux --with-sqlite3 --with-gnutls --with-libsystemd
 --with-threads --with-tree-sitter --without-wide-int --with-sound=alsa
 --with-zlib --with-x --without-pgtk --without-ns --without-gconf
 --without-gsettings --without-toolkit-scroll-bars --with-xpm --with-xft
 --with-cairo --with-harfbuzz --without-libotf --without-m17n-flt
 --with-x-toolkit=gtk3 --without-xwidgets --with-gif --with-jpeg
 --with-png --with-rsvg --with-tiff --with-webp --with-imagemagick
 --with-dumping=pdumper 'CFLAGS=-O2 -pipe' 'LDFLAGS=-Wl,-O1
 -Wl,--as-needed''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ IMAGEMAGICK
JPEG JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER WEBP X11
XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C.utf8
  value of $LC_MONETARY: en_GB.utf8
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

bug#66638: 29.1; `file-relative-name' and symbolic links

[Eli Zaretskii]

tags 66638 notabug
thanks

> From: Bogdan Ruslanovich Drozd <bogdan.ruslanovich.drozd@yandex.com>
> Date: Thu, 19 Oct 2023 16:36:20 +0300
> 
> How I found the bug: LaTeX previews were not displayed in Org mode
> because the path where the file lies contains a symbolic link
> (e.g. `/home/user/docs/org' directory where `/home/user/docs' is a
> symbolic link to a directory).
> 
> Bug description: `file-relative-name' (in `files.el') doesn't take into
> account symbolic links.
> 
> How to reproduce:
> 
> 1. Run `mkdir -p ~/a_dir/org'.
> 
> 2. Run `ln -s ~/a_dir/org ~/docs'.
> 
> 3. Run `emacs -Q ~/docs/example.org'.
> 
> 4. Insert into the file "$2+2=4$", press `C-c C-x C-l', and see that it
> does not work.
> 
> 5. Kill emacs.
> 
> 6. Run `emacs -Q ~/a_dir/org/example.org'.
> 
> 7. Insert into the file "$2+2=4$, press `C-c C-x C-l', and see LaTeX
> preview.

This is not a bug.  If you want to resolve symlinks in a file name,
use file-truename before calling file-relative-name.  The latter is
purely a syntactic function which merely analyzes its file name
argument, and should not hit the disk.

bug#66638: 29.1; `file-relative-name' and symbolic links

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 66638 notabug
> thanks
>
>> From: Bogdan Ruslanovich Drozd <bogdan.ruslanovich.drozd@yandex.com>
>> Date: Thu, 19 Oct 2023 16:36:20 +0300
>>
>> How I found the bug: LaTeX previews were not displayed in Org mode
>> because the path where the file lies contains a symbolic link
>> (e.g. `/home/user/docs/org' directory where `/home/user/docs' is a
>> symbolic link to a directory).
>>
>> Bug description: `file-relative-name' (in `files.el') doesn't take into
>> account symbolic links.
>>
>> How to reproduce:
>>
>> 1. Run `mkdir -p ~/a_dir/org'.
>>
>> 2. Run `ln -s ~/a_dir/org ~/docs'.
>>
>> 3. Run `emacs -Q ~/docs/example.org'.
>>
>> 4. Insert into the file "$2+2=4$", press `C-c C-x C-l', and see that it
>> does not work.
>>
>> 5. Kill emacs.
>>
>> 6. Run `emacs -Q ~/a_dir/org/example.org'.
>>
>> 7. Insert into the file "$2+2=4$, press `C-c C-x C-l', and see LaTeX
>> preview.
>
> This is not a bug.  If you want to resolve symlinks in a file name,
> use file-truename before calling file-relative-name.  The latter is
> purely a syntactic function which merely analyzes its file name
> argument, and should not hit the disk.

I'm therefore closing this bug report.