Subject: Re: bug#34834: 26.1; Remote `eshell/mv' and `eshell/cp' on Windows: Opening output file: Invalid argument, c:/home/ ...

From: Michael Albinus <[email-masked]>
Date: Fri, 29 Mar 2019 12:16:17 +0100

Eli Zaretskii <[email-masked]> writes:

Hi Eli,

>> Remote file names shouldn't get a drive letter. But this happened:
>
> Can you describe how this is supposed to work?  AFAIR, Tramp's
> file-name handler gets called, and then turns around and calls back
> into expand-file-name after inhibiting file-name handlers?  Or
> something like that.

I have an idea what happened. See the traces I gave in my first answer:

======================================================================
1 -> (expand-file-name "123" "tmp/")
| 2 -> (tramp-file-name-handler expand-file-name "tmp/" "/plinkx:detlefx:/home/albinus/")
| | 3 -> (tramp-sh-handle-expand-file-name "tmp/" "/plinkx:detlefx:/home/albinus/")
| | | 4 -> (tramp-file-name-handler file-name-as-directory "/plinkx:detlefx:/home/albinus/")
| | | 4 <- tramp-file-name-handler: "/plinkx:detlefx:/home/albinus/"
| | | 4 -> (expand-file-name "/home/albinus/tmp/")
| | | 4 <- expand-file-name: "c:/home/albinus/tmp/"
| | 3 <- tramp-sh-handle-expand-file-name: "/plinkx:detlefx:/home/albinus/tmp/"
| 2 <- tramp-file-name-handler: "/plinkx:detlefx:/home/albinus/tmp/"
1 <- expand-file-name: "c:/plinkx:detlefx:/home/albinus/tmp/123"
======================================================================

The buffer's default-directory is remote, "/plinkx:detlefx:/home/albinus/".
expand-file-name is called

--8<---------------cut here---------------start------------->8---
(expand-file-name "123" "tmp/")
--8<---------------cut here---------------end--------------->8---

This is entry "1" in the trace output. In function Fexpand_file_name,
line 794 of fileio.c, there is the check

--8<---------------cut here---------------start------------->8---
  handler = Ffind_file_name_handler (name, Qexpand_file_name);
--8<---------------cut here---------------end--------------->8---

This returns Qnil, because name is "123". Then we have in line 823

--8<---------------cut here---------------start------------->8---
  handler = Ffind_file_name_handler (default_directory, Qexpand_file_name);
--8<---------------cut here---------------end--------------->8---

This returns Qnil again, because default_directory is "tmp/". That's all
about checking for a file name handler. Later on, line 872, there is

--8<---------------cut here---------------start------------->8---
	default_directory = Fexpand_file_name (default_directory, Qnil);
--8<---------------cut here---------------end--------------->8---

which belongs to entry "2" of the traces above. It returns the proper
answer "/plinkx:detlefx:/home/albinus/tmp/". But this is too late; it
must happen before the second call of Ffind_file_name_handler.
Fexpand_file_name continues to work, it constructs the final answer
"/plinkx:detlefx:/home/albinus/tmp/123" *plus* the drive letter (I
suppose line 1047),

As you know, I cannot test it myself any fix, because I cannot build
Emacs for Windows.

> Meanwhile, the same problem happens in Emacs 26, so this is not new.

Yes. It is not so common to use a relative dir argument for
expand-file-name, and in the non-Windows case it works properly. So it
was uncovered for years.

Best regards, Michael.