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

Previous Next

Package: emacs;

Reported by: Nan JunJie <nanjunjie <at> 139.com>

Date: Wed, 4 Oct 2023 12:53:03 UTC

Severity: normal

Found in version 30.0.50

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nan JunJie <nanjunjie <at> 139.com>
Cc: 66340 <at> debbugs.gnu.org
Subject: 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.




This bug report was last modified 1 year and 318 days ago.

Previous Next


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