GNU bug report logs - #33564
Incorrect path canonicalisation

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33564 in the body.
You can then email your comments to 33564 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Mattias Andrée <maandree <at> kth.se>
To: bug-gnu-emacs <at> gnu.org
Subject: Incorrect path canonicalisation
Date: Sat, 1 Dec 2018 21:04:50 +0100

Emacs 26.1 removes ..'s incorrectly from file names.
Emacs removes the directory in front the .. rather than
getting its parent directory.

Example:

	cd
	mkdir -p 1/2
	cd 1/2
	echo 3 > ../../3
	ln -s ~ 4
	echo 5 > 5
	emacs 4/../5 # works, but shouldn't
	emacs 4/../$USER/3 # does not works, should

On Linux, the proper way to get the canonical path
for a file with the file descriptor $fd:

	stat(3) /dev/fd/$fd
	p := readlink(3) /dev/fd/$fd
	if (st_nlinks != 0) {
		stat(3) /dev/fd/$fd
		if (st_nlinks == 0) {
			p := readlink(3) /dev/fd/$fd
			remove " (deleted)" from the end of p
		}
	} else {
		remove " (deleted)" from the end of p
	}
	canonical path is p

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Mattias Andrée <maandree <at> kth.se>
Cc: 33564 <at> debbugs.gnu.org
Subject: Re: bug#33564: Incorrect path canonicalisation
Date: Sat, 01 Dec 2018 21:27:27 +0100

On Dez 01 2018, Mattias Andrée <maandree <at> kth.se> wrote:

> Emacs 26.1 removes ..'s incorrectly from file names.
> Emacs removes the directory in front the .. rather than
> getting its parent directory.

This is deliberate.  Emacs never consults the filesystem when
canonicalizing filenames, as documented in expand-file-name.  This is
consistent with the logical view of the filesystem, and how the shell
builtin cd handles it.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Andrée <maandree <at> kth.se>
Cc: 33564 <at> debbugs.gnu.org
Subject: Re: bug#33564: Incorrect path canonicalisation
Date: Sat, 01 Dec 2018 22:30:49 +0200

tags 33564 notabug
thanks

> Date: Sat, 1 Dec 2018 21:04:50 +0100
> From: Mattias Andrée <maandree <at> kth.se>
> 
> 	cd
> 	mkdir -p 1/2
> 	cd 1/2
> 	echo 3 > ../../3
> 	ln -s ~ 4
> 	echo 5 > 5
> 	emacs 4/../5 # works, but shouldn't
> 	emacs 4/../$USER/3 # does not works, should

This is by design: expand-file-name doesn't follow symlinks.  It's
documented not to do that: see the doc string and the ELisp manual.

> On Linux, the proper way to get the canonical path
> for a file with the file descriptor $fd:

expand-file-name doesn't aim at yielding the canonical file name in
that sense.

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

From: Mattias Andrée <maandree <at> kth.se>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 33564 <at> debbugs.gnu.org
Subject: Re: bug#33564: Incorrect path canonicalisation
Date: Sat, 1 Dec 2018 21:35:14 +0100

On Sat, 1 Dec 2018 21:27:27 +0100
Andreas Schwab <schwab <at> linux-m68k.org> wrote:

> On Dez 01 2018, Mattias Andrée <maandree <at> kth.se> wrote:
> 
> > Emacs 26.1 removes ..'s incorrectly from file names.
> > Emacs removes the directory in front the .. rather than
> > getting its parent directory.  
> 
> This is deliberate.  Emacs never consults the filesystem when
> canonicalizing filenames, as documented in expand-file-name.  This is
> consistent with the logical view of the filesystem, and how the shell
> builtin cd handles it.

What is the rationale for this? No other program Bash and Emacs
behave this way, including the coreutils.

It seems odd that the Bash suggest file from the wrong directory
so that even the coreutils cannot find them, only Emacs.

> 
> Andreas.
> 

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Mattias Andrée <maandree <at> kth.se>
Cc: 33564 <at> debbugs.gnu.org
Subject: Re: bug#33564: Incorrect path canonicalisation
Date: Sat, 01 Dec 2018 21:55:29 +0100

On Dez 01 2018, Mattias Andrée <maandree <at> kth.se> wrote:

> On Sat, 1 Dec 2018 21:27:27 +0100
> Andreas Schwab <schwab <at> linux-m68k.org> wrote:
>
>> On Dez 01 2018, Mattias Andrée <maandree <at> kth.se> wrote:
>> 
>> > Emacs 26.1 removes ..'s incorrectly from file names.
>> > Emacs removes the directory in front the .. rather than
>> > getting its parent directory.  
>> 
>> This is deliberate.  Emacs never consults the filesystem when
>> canonicalizing filenames, as documented in expand-file-name.  This is
>> consistent with the logical view of the filesystem, and how the shell
>> builtin cd handles it.
>
> What is the rationale for this?

Canonicalizing is a pure textual operation.

> No other program Bash and Emacs behave this way, including the
> coreutils.

This is not true, as I explained above.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

From: Mattias Andrée <maandree <at> kth.se>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 33564 <at> debbugs.gnu.org
Subject: Re: bug#33564: Incorrect path canonicalisation
Date: Sat, 1 Dec 2018 22:14:30 +0100

On Sat, 1 Dec 2018 21:55:29 +0100
Andreas Schwab <schwab <at> linux-m68k.org> wrote:

> On Dez 01 2018, Mattias Andrée <maandree <at> kth.se> wrote:
> 
> > On Sat, 1 Dec 2018 21:27:27 +0100
> > Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> >  
> >> On Dez 01 2018, Mattias Andrée <maandree <at> kth.se> wrote:
> >>   
> >> > Emacs 26.1 removes ..'s incorrectly from file names.
> >> > Emacs removes the directory in front the .. rather than
> >> > getting its parent directory.    
> >> 
> >> This is deliberate.  Emacs never consults the filesystem when
> >> canonicalizing filenames, as documented in expand-file-name.  This is
> >> consistent with the logical view of the filesystem, and how the shell
> >> builtin cd handles it.  
> >
> > What is the rationale for this?  
> 
> Canonicalizing is a pure textual operation.

Yes, you said, but why should Emacs canonicalise the file names
given in the command line in the first place? One would expect
that if you examine a file with for example stat or cat, you
with be working with that file with you give Emacs the same
file name.

> 
> > No other program Bash and Emacs behave this way, including the
> > coreutils.  
> 
> This is not true, as I explained above.

Okay, dash also behaves this way, but ls, cat, and nano, for example
don't (and no, you didn't explain, nor should you have, you should
have given counter examples, preferably GNU program). I don't know any
other program that behaves this way. The same think goes for resolving
~, normal programs use the file names given in the command line as is.

> 
> Andreas.
> 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Andrée <maandree <at> kth.se>
Cc: schwab <at> linux-m68k.org, 33564 <at> debbugs.gnu.org
Subject: Re: bug#33564: Incorrect path canonicalisation
Date: Sun, 02 Dec 2018 08:27:33 +0200

> Date: Sat, 1 Dec 2018 22:14:30 +0100
> From: Mattias Andrée <maandree <at> kth.se>
> Cc: 33564 <at> debbugs.gnu.org
> 
> why should Emacs canonicalise the file names given in the command
> line in the first place?

One reason is so that it could meaningfully compare file names as
strings.  Another reason is that relative file names change their
meaning when you switch buffers, because Emacs behaves in a way that
switching buffers conceptually changes your working directory to the
directory of that buffer.

Message #30 received at 33564-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mattias Andrée <maandree <at> kth.se>,
 33564-done <at> debbugs.gnu.org
Subject: Re: bug#33564: Incorrect path canonicalisation
Date: Wed, 21 Aug 2019 04:26:51 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 33564 notabug
> thanks
>
>> Date: Sat, 1 Dec 2018 21:04:50 +0100
>> From: Mattias Andrée <maandree <at> kth.se>
>>
>>     cd
>>     mkdir -p 1/2
>>     cd 1/2
>>     echo 3 > ../../3
>>     ln -s ~ 4
>>     echo 5 > 5
>>     emacs 4/../5 # works, but shouldn't
>>     emacs 4/../$USER/3 # does not works, should
>
> This is by design: expand-file-name doesn't follow symlinks.  It's
> documented not to do that: see the doc string and the ELisp manual.
>
>> On Linux, the proper way to get the canonical path
>> for a file with the file descriptor $fd:
>
> expand-file-name doesn't aim at yielding the canonical file name in
> that sense.

This was tagged notabug in December 2018; I'm now also closing this bug report.

Thanks,
Stefan Kangas

Previous Next

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