Re: Change in 28.1 in opening a file from grep results on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Pascal Quesseveur <pquessev@gmail.com>
> Date: Tue, 12 Jul 2022 18:31:25 +0200
> 
> >"EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> 
>   EZ> This is not entirely clear: what exactly happens when you do
>   EZ> that?  If you see error messages, please show the exact text of
>   EZ> those messages.
> 
> It is not an Emacs error. It is an error coming from the launched
> process.
> 
> \\smbserver\foo
> CMD.exe été démarré avec le chemin d'accès comme répertoire en cours.
> Les chemins d'accès UNC ne sont pas pris en charge....

I know that the error comes from cmd.exe.  But I wanted to see what
kind of commands trigger it.

Is the command that you have shown something you actually type from
Emacs?  If so, for what purpose?

Your original description was:

> I execute grep from c:\Users\Public\app\file1.c. When I open a file in
> results buffer (eg file2.c), the file is opened with its true name,
> \\smbserver\app\file2.c, and then I can not execute same command as
> before on file1.c because cmd.exe is not allowed from a remote
> directory.

So what is that "same command as before on file1.c"?  And if you
invoke it, how does the error manifest itself?  E.g., does Emacs
signal an error and/or enter the Lisp debugger and show Lisp
backtrace?

>   EZ> As a workaround: can you map the directory on the SMB server to a
>   EZ> drive letter, and then change the symbolic link to use that drive
>   EZ> letter instead of the literal \\smbserver\foo\ remote directory?  If
>   EZ> you do that, does it work around the problem?
> 
> Yes it does. But it is not what I want. And it used to work until last
> Emacs version. So my question is: was the change made for some
> legitimate reason or is it just cosmetic?

I answered that question in my previous message: it wasn't a cosmetic
change.