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

Previous Next

Full log

Message #8 received at 66340 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nan JunJie <nanjunjie <at> 139.com>
Cc: 66340 <at> debbugs.gnu.org
Subject: Re: bug#66340: 30.0.50;
 file-relative-name not correct if default-directory with symbolic link
Date: Wed, 04 Oct 2023 19:49:28 +0300

> From: Nan JunJie <nanjunjie <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.