bug#66340: 30.0.50; file-relative-name not correct if default-directory with symbolic link

bug#66340: 30.0.50; file-relative-name not correct if default-directory with symbolic link

[Nan JunJie]

for example, say I have below symbolic link:

/home/nanjj/tmp/nanjj.github.io ->
/home/nanjj/src/githu.com/nanjj/nanjj.github.io

I run (file-relative-name "/tmp") under /home/nanjj/tmp/nanjj.github.io,
it should output "../../../../../../../tmp" instead of
"../../../../tmp".

One possible fix listed as below:

From 21936e7aca04db7ab00f98d0265afa900d27177e Mon Sep 17 00:00:00 2001
From: Nan Jun Jie <nanjunjie@139.com>
Date: Wed, 4 Oct 2023 19:10:04 +0800
Subject: [PATCH] Fixed file-relative-name issue

if default-directory has symbolic link in the path, the
file-relative-name result is not correct.
---
 lisp/files.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/files.el b/lisp/files.el
index ddae097f1d1..124710dde48 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -5545,8 +5545,9 @@ file-relative-name
 on a DOS/Windows machine, it returns FILENAME in expanded form."
   (save-match-data
     (setq directory
-	  (file-name-as-directory (expand-file-name (or directory
-							default-directory))))
+          (file-truename
+	   (file-name-as-directory (expand-file-name (or directory
+							 default-directory)))))
     (setq filename (expand-file-name filename))
     (let ((fremote (file-remote-p filename))
 	  (dremote (file-remote-p directory))
-- 
2.40.1



-- 
https://nanjj.srht.site
 ∧ ∧︵
ミ^ō^ミ灬)～
https://nanjj.github.io

bug#66340: 30.0.50; file-relative-name not correct if default-directory with symbolic link

[Eli Zaretskii]

> From: Nan JunJie <nanjunjie@139.com>
> Date: Wed, 04 Oct 2023 19:25:01 +0800
> 
> 
> for example, say I have below symbolic link:
> 
> /home/nanjj/tmp/nanjj.github.io ->
> /home/nanjj/src/githu.com/nanjj/nanjj.github.io
> 
> I run (file-relative-name "/tmp") under /home/nanjj/tmp/nanjj.github.io,
> it should output "../../../../../../../tmp" instead of
> "../../../../tmp".
> 
> One possible fix listed as below:

Thanks, but that fix cannot be right.  file-relative-name is a
purely-syntactic function, which analyzes the argument file name
without ever hitting the disk.  So calling file-truename from it is
not TRT.

I think your expectations from file-relative-name are simply
incorrect: if an application needs to resolve symlinks, it should do
that itself, like this:

  (file-relative-name "/tmp" (file-truename default-directory))

IOW, I don't think there's a bug in file-relative-name in this case.