From: Richard Copley <rcopley@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>, 28207@debbugs.gnu.org
Subject: bug#28207: 26.0.50; MS Windows UNC file names complete as directory names
Date: Fri, 25 Aug 2017 14:56:38 +0100 [thread overview]
Message-ID: <CAPM58oiJx2-oMri_Ynm2OXTr003sy34fpMB9-q8d=V5UC-cbdQ@mail.gmail.com> (raw)
In-Reply-To: <CAPM58ohAqvOfvok_V2X6=pQOraTRru03DfAq6jzief12CgeweA@mail.gmail.com>
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.
next prev parent reply other threads:[~2017-08-25 13:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-23 15:54 bug#28207: 26.0.50; MS Windows UNC file names complete as directory names Richard Copley
2017-08-25 13:56 ` Richard Copley [this message]
2017-08-25 14:54 ` Eli Zaretskii
2017-08-25 15:35 ` Richard Copley
2017-08-25 15:49 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPM58oiJx2-oMri_Ynm2OXTr003sy34fpMB9-q8d=V5UC-cbdQ@mail.gmail.com' \
--to=rcopley@gmail.com \
--cc=28207@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).