GNU bug report logs - #15130
24.3.50; emacs-24.3.1 on Windows; possible `file-directory-p' bug.

Previous Next

Full log

View this message in rfc822 format

From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15130 <at> debbugs.gnu.org
Subject: bug#15130: 24.3.50; emacs-24.3.1 on Windows; possible `file-directory-p' bug.
Date: Tue, 20 Aug 2013 08:35:13 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
>> Date: Mon, 19 Aug 2013 10:47:24 +0200
>> 
>> On windows `file-directory-p' returns t on a path with a space added at
>> end.
>> 
>> ;; windows-nt
>> (file-directory-p "c:/Program Files/emacs-24.3-bin-i386/emacs-24.3/site-lisp/")
>> t
>> (file-directory-p "c:/Program Files/emacs-24.3-bin-i386/emacs-24.3/site-lisp/ ")
>> t
>> ;; gnu/linux
>> (file-directory-p "~/.emacs.d/")
>> t
>> (file-directory-p "~/.emacs.d/ ")
>> nil
>> 
>> Is it wanted?
>
> It's wanted only if you really have a directory named " " under 
> 'c:/Program Files/emacs-24.3-bin-i386/emacs-24.3/site-lisp/' ;-)
>
> Seriously, though: this is not Emacs's fault.  There's no code in
> Emacs that removes that space from the name; we simply hand the
> (expanded) file name to the Windows API that returns file attributes,
> and if the returned attributes say it's a directory, we return t.
>
> More generally, all Win32 APIs ignore trailing whitespace in file
> names.  OTOH, it _is_ possible to create file names such as "/foo/ "
> on Windows (by using a file-name syntax that bypasses the Win32
> file-name normalization layer), so rejecting file names such as the
> one you show is not an option.  On the third hand, converting every
> file name to that syntax internally, so that we bypass the
> normalization, is a large job, whose risks are unknown, at least to
> me, and whose gains are quite small, since use cases where you trip
> upon such problems are very rare

Of course, fixing that on the emacs side is not an option.

> (can you tell what was your use case, btw?).

If I enter in minibuffer e.g "~/.emacs.d" helm detect that ".emacs.d" is
a directory, append a "/" and give completion on this directory.
When I enter in minibuffer "~/.emacs.d/ " it wait for multi regexp
completion, e.g I can enter then "~/.emacs.d/ i ni el" or 
"~/.emacs.d/ el$" to complete "init.el" or all *.el files in this directory.
On Windows, as soon I enter the trailing space, the directory (which
doesn't exists) "~/.emacs.d/ " is detected and the end slash is added to
complete against "~/.emacs.d/ /" which is unwanted.
Though hitting C-<backspace> disable this feature and allow entering a
space without instant completion.

> So I think we will have to continue living with this idiosyncrasy of
> Windows filesystems.

Yes. Thanks for explanations, probably you can close this bug.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Previous Next

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