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

[Eli Zaretskii]

> Date: Fri, 29 Mar 2019 20:46:10 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: jordan.t.wilson@gmx.com, 34834@debbugs.gnu.org
> 
> > From: Michael Albinus <michael.albinus@gmx.de>
> > Cc: jordan.t.wilson@gmx.com,  34834@debbugs.gnu.org
> > Date: Fri, 29 Mar 2019 17:02:27 +0100
> > 
> > While you are at this, do you have a chance to check bug#26911? It is
> > another problem, but also somewhere in Fexpand_file_name.
> 
> Will do.

And then I didn't.

Re-reading all that discussion now, I come to the conclusion that I
need your help, Michael, to understand your analysis in more detail.

Back then, you said:

> ======================================================================
> 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),

Could you please elaborate on the "this is too late" part?  What
exactly should have happened "before the second call of
Ffind_file_name_handler", and how would that help to fix this problem,
in your opinion?

I'm asking because the straightforward way of fixing this seems to
notice that the buffer's default-directory is remote, and refrain from
adding the drive letter in that case.  However, your comments above
seem to hint that another, perhaps simpler and/or more elegant, way
should be possible, and I wonder what could that other way be.

TIA