bug#28207: 26.0.50; MS Windows UNC file names complete as directory names

[Richard Copley]

On 23 August 2017 at 16:54, Richard Copley <rcopley@gmail.com> wrote:
> C-x C-f //server/share/filename TAB
>
> Expected result: completes to "//server/share/filename".
> Actual result: completes to "//server/share/filename/".

You don't need a network share to recreate the symptom.
"//localhost/c$/temp/x.txt" will do.

For info, this symptom starts happening in this commit:

commit fce2b2d2b40a1c0505d1ad623baef76f726c436a
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Sat Aug 12 14:44:20 2017 +0300

  Fix completion on directory names on MS-DOS/MS-Windows

  * src/msdos.c (faccessat):
  * src/w32.c (faccessat): Support relative file names, and add D_OK
  to 'mode' if the argument is a directory.  This unbreaks file-name
  completion when the completion result is a directory.

I looked at what the code was doing but I didn't get to the bottom
of it.

Perhaps because of
  if (is_unc_volume (filename)) [...] return NULL;
in sys_opendir in w32.c?

(So the global variable dir_pathname doesn't get set.)

Or perhaps to do with file_name_completion in dired.c:
     case DT_LNK: case DT_UNKNOWN:
      directoryp = file_name_completion_dirp (fd, dp, len);

(So directoryp is true if the file name in dp ends in a slash,
but we later interpret directoryp to mean the file name is the
name of an existing directory.)

Or perhaps both, or neither.