--- Begin Message ---
|
Subject: |
23.1; UNC paths of the form "//DFSROOT/SHARE" |
|
Date: |
Thu, 8 Oct 2009 14:43:21 +0100 |
On Windows in a domain environment, suppose "//DFSROOT" is a
domain-hosted DFS root, with a share "//DFSROOT/SHARE". (Typically,
DFSROOT will be the name of the domain.)
Interactively, using "C-x C-f / / D F S R O O T / S H A R E RET"
causes an error: "completion--some: Opening directory: invalid
argument, //DFSROOT/". This occurs in Emacs 23.1 but not in Emacs
22.3. I haven't looked into the completion code to see why. This is a
bug.
Note: The list returned by the form (directory-files-and-attributes
"//DFSROOT/SHARE") contains the list ("..") as an element. Evaluating
(directory-files-and-attributes "//DFSROOT") signals an error "Opening
directory: invalid argument, //DFSROOT". This occurs on Emacs 22.3 as
well as Emacs 23.1 and is probably the correct behaviour.
Therefore, in Emacs 23.1 but not in Emacs 22.3, when visiting the
directory "//DFSROOT/SHARE" by evaluating (find-file
"//DFS-ROOT/SHARE"), the function `ls-lisp-insert-directory' fails,
because it does not account for the possibility that an entry in the
list returned by `directory-files-and-attributes' may be missing the
attribute data. The error signalled is "Format specifier doesn't match
argument type", arising from the form (format "%d" fuid) where fuid is
nil. This is a bug. To reproduce, run Emacs 23.1 in a domain
environment where domain-hosted DFS is in use, and visit a directory
of the form "//DOMAIN/SHARE" or "//DFSROOT/SHARE" by evaluating the
expression (find-file "//DFSROOT/SHARE").
Note that the more familiar UNC paths of the form "//SERVER/SHARE",
where SERVER is the name of a computer, will not cause these errors.
In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
of 2009-07-30 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENG
value of $XMODIFIERS: nil
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Fundamental
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
global-auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
C-x C-f / / u h b / w c l <return> C-g M-: ( f i n
d - f i l e SPC " / / u h b / w c l " ) <return> q M-x r e p o
r t SPC e m a c s - b u g <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
completion--some: Opening directory: invalid argument, //uhb/
Quit
Entering debugger...
Back to top level.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#4674: 23.1; UNC paths and file-relative-directory |
|
Date: |
Sat, 04 Dec 2010 14:55:28 +0200 |
> Date: Thu, 8 Oct 2009 14:54:38 +0100
> From: Richard Copley <address@hidden>
> Cc:
>
> The function `file-relative-directory' has logic to detect when the
> two given paths are part of two separate directory trees, and to
> return the absolute file name in such cases. That logic does not catch
> the case when the two given paths are UNC paths on different servers.
> For example, on my present network (where there are computers named
> IOBATES and KERES), the form (file-relative-name "//iobates/e/temp"
> "//keres/e/temp") returns "../../../iobates/e/temp", which is not a
> valid relative path to "//iobates/e/temp" from "//keres/e/temp". This
> is therefore a bug.
Thanks, I fixed this now on the Emacs-23 branch.
--- End Message ---