bug#33564: Incorrect path canonicalisation

bug#33564: Incorrect path canonicalisation

[Mattias Andrée]

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

bug#33564: Incorrect path canonicalisation

[Andreas Schwab]

On Dez 01 2018, Mattias Andrée <maandree@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#33564: Incorrect path canonicalisation

[Eli Zaretskii]

tags 33564 notabug
thanks

> Date: Sat, 1 Dec 2018 21:04:50 +0100
> From: Mattias Andrée <maandree@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.

bug#33564: Incorrect path canonicalisation

[Mattias Andrée]

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

> On Dez 01 2018, Mattias Andrée <maandree@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.
> 

bug#33564: Incorrect path canonicalisation

[Andreas Schwab]

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

> On Sat, 1 Dec 2018 21:27:27 +0100
> Andreas Schwab <schwab@linux-m68k.org> wrote:
>
>> On Dez 01 2018, Mattias Andrée <maandree@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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#33564: Incorrect path canonicalisation

[Mattias Andrée]

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

> On Dez 01 2018, Mattias Andrée <maandree@kth.se> wrote:
> 
> > On Sat, 1 Dec 2018 21:27:27 +0100
> > Andreas Schwab <schwab@linux-m68k.org> wrote:
> >  
> >> On Dez 01 2018, Mattias Andrée <maandree@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.
> 

bug#33564: Incorrect path canonicalisation

[Eli Zaretskii]

> Date: Sat, 1 Dec 2018 22:14:30 +0100
> From: Mattias Andrée <maandree@kth.se>
> Cc: 33564@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.

bug#33564: Incorrect path canonicalisation

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> tags 33564 notabug
> thanks
>
>> Date: Sat, 1 Dec 2018 21:04:50 +0100
>> From: Mattias Andrée <maandree@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