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

Previous Next

Full log

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jordan.t.wilson <at> gmx.com, 34834 <at> debbugs.gnu.org
Subject: Re: bug#34834: 26.1;
 Remote `eshell/mv' and `eshell/cp' on Windows: Opening output file:
 Invalid argument, c:/home/ ...
Date: Fri, 29 Mar 2019 12:16:17 +0100

Eli Zaretskii <eliz <at> gnu.org> 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.

Previous Next

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