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

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

[Richard Copley]

To reproduce from emacs -Q on MS Windowss, assuming
a file called "//server/share/filename" exists on
the network,

C-x C-f //server/share/filename TAB

Expected result: completes to "//server/share/filename".
Actual result: completes to "//server/share/filename/".

In GNU Emacs 26.0.50 (build 1, x86_64-w64-mingw32)
 of 2017-08-22 built on 60678UHB
Repository revision: 036a92eb006cc175d13ad7ada80225eb8340724d
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/mingw64 --config-cache --with-modules
 --without-pop CFLAGS=-O2'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 97909 11263)
 (symbols 56 20127 1)
 (miscs 48 36 86)
 (strings 32 30095 1184)
 (string-bytes 1 780930)
 (vectors 16 14656)
 (vector-slots 8 486478 6114)
 (floats 8 50 103)
 (intervals 56 233 0)
 (buffers 992 11))

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.

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

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Fri, 25 Aug 2017 14:56:38 +0100
> 
> 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/".

Thanks, should be fixed now.

> Or perhaps both, or neither.

No, it was a stupid thinko in the emulated faccessat, that worked on
local files by sheer luck.

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

[Richard Copley]

On 25 August 2017 at 15:54, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Richard Copley <rcopley@gmail.com>
>> Date: Fri, 25 Aug 2017 14:56:38 +0100
>>
>> 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/".
>
> Thanks, should be fixed now.
>
>> Or perhaps both, or neither.
>
> No, it was a stupid thinko in the emulated faccessat, that worked on
> local files by sheer luck.

Fixed, thank you.

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

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Fri, 25 Aug 2017 16:35:36 +0100
> Cc: 28207@debbugs.gnu.org
> 
> >> > Expected result: completes to "//server/share/filename".
> >> > Actual result: completes to "//server/share/filename/".
> >
> > Thanks, should be fixed now.
> >
> >> Or perhaps both, or neither.
> >
> > No, it was a stupid thinko in the emulated faccessat, that worked on
> > local files by sheer luck.
> 
> Fixed, thank you.

Thanks for testing, closing.