GNU bug report logs - #4673
23.1; UNC paths of the form "//DFSROOT/SHARE"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4673 in the body.
You can then email your comments to 4673 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
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.

Message #12 received at 4673-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>, 4674-done <at> debbugs.gnu.org,
	4673-done <at> debbugs.gnu.org
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 <rcopley <at> gmail.com>
> 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.

Message #24 received at 4673 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: 4673 <at> debbugs.gnu.org
Subject: Not the same as 4674
Date: Tue, 31 Jan 2012 11:51:27 +0000

This is a separate bug from 4673 (which I believe is fixed). Can they
be un-merged?

Visiting a Windows DFS share when ".." is not accessible still crashes
in `ls-lisp-insert-directory' in the trunk of Emacs, as the attribute
list for ".." in the `file-alist' returned for by
`directory-files-and-attributes' is empty.

Namely, (directory-files-and-attributes "//root/share" nil nil t
'string) returns something like this:

   '(("." t 1 "RCO" "Domain Users" (20263 19364) (20263 19364) (18713
25576) 0 "drwxrwxrwx" nil 0 (18463 . 35684))
     ("..")
     ("file 1.csv" nil 1 "RCO" "Domain Users" (18744 6249) (18713
32060) (18713 25866) 13008 "-rw-rw-rw-" nil 0 (18463 . 35684))
     ("file 2.csv" nil 1 "RCO" "Domain Users" (20043 4789) (20043
4789) (20043 4789) 19134 "-rw-rw-rw-" nil 0 (18463 . 35684))
     ("file 3.csv" nil 1 "RCO" "Domain Users" (18788 55198) (20263
52634) (18788 55198) 29596 "-rw-rw-rw-" nil 0 (18463 . 35684))))

Meanwhile, back in `ls-lisp-insert-directory', (format "%d" fuid)
fails with (error "Format specifier doesn't match argument type").

Message #29 received at 4673 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 4673 <at> debbugs.gnu.org
Subject: Re: bug#4673: Not the same as 4674
Date: Fri, 03 Feb 2012 13:18:12 +0200

> Date: Tue, 31 Jan 2012 11:51:27 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> 
> This is a separate bug from 4673 (which I believe is fixed). Can they
> be un-merged?

Done.

> Visiting a Windows DFS share when ".." is not accessible still crashes
> in `ls-lisp-insert-directory' in the trunk of Emacs, as the attribute
> list for ".." in the `file-alist' returned for by
> `directory-files-and-attributes' is empty.

What does the following yield for a DFS share?

  M-: (file-attributes "//root/share/.." 'string) RET

For that matter, what does the following cmd command display?

  dir /n/q/a:d \\root\share

> Meanwhile, back in `ls-lisp-insert-directory', (format "%d" fuid)
> fails with (error "Format specifier doesn't match argument type").

I will work on making ls-lisp-insert-directory be more tolerant of
such use cases, but it is important for me to understand whether or
not there is really a ".." entry on such shares, as this will
determine if we want to display them in some way or simply omit them
from the directory listing in Dired.  The above questions will help me
make up my mind about that.

TIA

Message #32 received at 4673 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 4673 <at> debbugs.gnu.org
Subject: Re: bug#4673: Not the same as 4674
Date: Fri, 3 Feb 2012 12:17:31 +0000

On 3 February 2012 11:18, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Tue, 31 Jan 2012 11:51:27 +0000
>> From: Richard Copley <rcopley <at> gmail.com>
>>
>> This is a separate bug from 4673 (which I believe is fixed). Can they
>> be un-merged?
>
> Done.
>
>> Visiting a Windows DFS share when ".." is not accessible still crashes
>> in `ls-lisp-insert-directory' in the trunk of Emacs, as the attribute
>> list for ".." in the `file-alist' returned for by
>> `directory-files-and-attributes' is empty.
>
> What does the following yield for a DFS share?
>
>  M-: (file-attributes "//root/share/.." 'string) RET

nil.

> For that matter, what does the following cmd command display?
>
>  dir /n/q/a:d \\root\share


 Volume in drive \\root\share is Data
 Volume Serial Number is 0123-4567

 Directory of \\root\share

11/11/2011  12:34    <DIR>          BUILTIN\Administrators .
11/11/2011  12:34    <DIR>          BUILTIN\Administrators ..
               0 File(s)              0 bytes
               2 Dir(s)  123,456,789,000 bytes free


>> Meanwhile, back in `ls-lisp-insert-directory', (format "%d" fuid)
>> fails with (error "Format specifier doesn't match argument type").
>
> I will work on making ls-lisp-insert-directory be more tolerant of
> such use cases, but it is important for me to understand whether or
> not there is really a ".." entry on such shares, as this will
> determine if we want to display them in some way or simply omit them
> from the directory listing in Dired.  The above questions will help me
> make up my mind about that.

In cmd if the current directory is \\root\share then (just the same as
for c:\) "cd .." does not change directory and "dir /a:d ." and "dir
/a:d .." display the same thing.

> TIA

Thanks yourself.

Message #35 received at 4673 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 4673 <at> debbugs.gnu.org
Subject: Re: bug#4673: Not the same as 4674
Date: Sat, 04 Feb 2012 11:05:50 +0200

> Date: Fri, 3 Feb 2012 12:17:31 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 4673 <at> debbugs.gnu.org
> 
> >> Visiting a Windows DFS share when ".." is not accessible still crashes
> >> in `ls-lisp-insert-directory' in the trunk of Emacs, as the attribute
> >> list for ".." in the `file-alist' returned for by
> >> `directory-files-and-attributes' is empty.
> >
> > What does the following yield for a DFS share?
> >
> >  M-: (file-attributes "//root/share/.." 'string) RET
> 
> nil.
> 
> > For that matter, what does the following cmd command display?
> >
> >  dir /n/q/a:d \\root\share
> 
> 
>  Volume in drive \\root\share is Data
>  Volume Serial Number is 0123-4567
> 
>  Directory of \\root\share
> 
> 11/11/2011  12:34    <DIR>          BUILTIN\Administrators .
> 11/11/2011  12:34    <DIR>          BUILTIN\Administrators ..
>                0 File(s)              0 bytes
>                2 Dir(s)  123,456,789,000 bytes free

Can you test the patch below?  I don't have access to such shares, so
I cannot test it myself.  TIA.

Since ls-lisp.el is preloaded, you will either need to rebuild Emacs
(if you have the development environment and the Emacs sources), or
manually load the patched ls-lisp.el before invoking Dired.

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2012-02-04 02:10:22 +0000
+++ lisp/ChangeLog	2012-02-04 09:00:52 +0000
@@ -1,3 +1,9 @@
+2012-02-04  Eli Zaretskii  <eliz <at> gnu.org>
+
+	* ls-lisp.el (ls-lisp-sanitize): New function.
+	(ls-lisp-insert-directory): Use it to fix or remove any elements
+	in file-alist with missing attributes.  (Bug#4673)
+
 2012-02-04  Glenn Morris  <rgm <at> gnu.org>
 
 	* image.el (image-extension-data): Add obsolete alias.

=== modified file 'lisp/ls-lisp.el'
--- lisp/ls-lisp.el	2012-01-19 07:21:25 +0000
+++ lisp/ls-lisp.el	2012-02-04 08:55:21 +0000
@@ -331,6 +331,7 @@ not contain `d', so that a full listing 
 	     ;; do all bindings here for speed
 	     total-line files elt short file-size attr
 	     fuid fgid uid-len gid-len)
+	(setq file-alist (ls-lisp-sanitize file-alist))
 	(cond ((memq ?A switches)
 	       (setq file-alist
 		     (ls-lisp-delete-matching "^\\.\\.?$" file-alist)))
@@ -437,6 +438,22 @@ not contain `d', so that a full listing 
 	(message "%s: doesn't exist or is inaccessible" file)
 	(ding) (sit-for 2)))))		; to show user the message!
 
+(defun ls-lisp-sanitize (file-alist)
+  "Sanitize the elements in FILE-ALIST.
+Fixes any elements in the alist for directory entries whose file
+attributes are nil (meaning that `file-attributes' failed for
+them).  This is known to happen for some network shares, in
+particular for the \"..\" directory entry.
+
+If the \"..\" directory entry has nil attributes, the attributes
+are copied from the \".\" entry, if they are non-nil.  Otherwise,
+the offending element is removed from the list, as are any
+elements for other directory entries with nil attributes."
+  (if (and (null (cdr (assoc ".." file-alist)))
+	   (cdr (assoc "." file-alist)))
+      (setcdr (assoc ".." file-alist) (cdr (assoc "." file-alist))))
+  (rassq-delete-all nil file-alist))
+
 (defun ls-lisp-column-format (file-alist)
   "Insert the file names (only) in FILE-ALIST into the current buffer.
 Format in columns, sorted vertically, following GNU ls -C.

Message #38 received at 4673 <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 4673 <at> debbugs.gnu.org
Subject: Re: bug#4673: Not the same as 4674
Date: Tue, 7 Feb 2012 15:30:12 +0000

On 4 February 2012 09:05, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 3 Feb 2012 12:17:31 +0000
>> From: Richard Copley <rcopley <at> gmail.com>
>> Cc: 4673 <at> debbugs.gnu.org
>>
>> >> Visiting a Windows DFS share when ".." is not accessible still crashes
>> >> in `ls-lisp-insert-directory' in the trunk of Emacs, as the attribute
>> >> list for ".." in the `file-alist' returned for by
>> >> `directory-files-and-attributes' is empty.
...
> Can you test the patch below?  I don't have access to such shares, so
> I cannot test it myself.  TIA.
>
> Since ls-lisp.el is preloaded, you will either need to rebuild Emacs
> (if you have the development environment and the Emacs sources), or
> manually load the patched ls-lisp.el before invoking Dired.
>
> === modified file 'lisp/ChangeLog'
> --- lisp/ChangeLog      2012-02-04 02:10:22 +0000
> +++ lisp/ChangeLog      2012-02-04 09:00:52 +0000
> @@ -1,3 +1,9 @@
> +2012-02-04  Eli Zaretskii  <eliz <at> gnu.org>
> +
> +       * ls-lisp.el (ls-lisp-sanitize): New function.
> +       (ls-lisp-insert-directory): Use it to fix or remove any elements
> +       in file-alist with missing attributes.  (Bug#4673)
> +
>  2012-02-04  Glenn Morris  <rgm <at> gnu.org>
>
>        * image.el (image-extension-data): Add obsolete alias.
>
> === modified file 'lisp/ls-lisp.el'
> --- lisp/ls-lisp.el     2012-01-19 07:21:25 +0000
> +++ lisp/ls-lisp.el     2012-02-04 08:55:21 +0000
> @@ -331,6 +331,7 @@ not contain `d', so that a full listing
>             ;; do all bindings here for speed
>             total-line files elt short file-size attr
>             fuid fgid uid-len gid-len)
> +       (setq file-alist (ls-lisp-sanitize file-alist))
>        (cond ((memq ?A switches)
>               (setq file-alist
>                     (ls-lisp-delete-matching "^\\.\\.?$" file-alist)))
> @@ -437,6 +438,22 @@ not contain `d', so that a full listing
>        (message "%s: doesn't exist or is inaccessible" file)
>        (ding) (sit-for 2)))))          ; to show user the message!
>
> +(defun ls-lisp-sanitize (file-alist)
> +  "Sanitize the elements in FILE-ALIST.
> +Fixes any elements in the alist for directory entries whose file
> +attributes are nil (meaning that `file-attributes' failed for
> +them).  This is known to happen for some network shares, in
> +particular for the \"..\" directory entry.
> +
> +If the \"..\" directory entry has nil attributes, the attributes
> +are copied from the \".\" entry, if they are non-nil.  Otherwise,
> +the offending element is removed from the list, as are any
> +elements for other directory entries with nil attributes."
> +  (if (and (null (cdr (assoc ".." file-alist)))
> +          (cdr (assoc "." file-alist)))
> +      (setcdr (assoc ".." file-alist) (cdr (assoc "." file-alist))))
> +  (rassq-delete-all nil file-alist))
> +
>  (defun ls-lisp-column-format (file-alist)
>   "Insert the file names (only) in FILE-ALIST into the current buffer.
>  Format in columns, sorted vertically, following GNU ls -C.
>

I rebuilt from the patched sources, and (dired "//root/share") works
fine here now.
Thanks!

Message #41 received at 4673 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 4673 <at> debbugs.gnu.org
Subject: Re: bug#4673: Not the same as 4674
Date: Tue, 07 Feb 2012 19:30:51 +0200

> Date: Tue, 7 Feb 2012 15:30:12 +0000
> From: Richard Copley <rcopley <at> gmail.com>
> Cc: 4673 <at> debbugs.gnu.org
> 
> I rebuilt from the patched sources, and (dired "//root/share") works
> fine here now.

Thanks for testing, I will install the change soon.

Message #42 received at 4673-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rcopley <at> gmail.com
Cc: 4673-done <at> debbugs.gnu.org
Subject: Re: bug#4673: Not the same as 4674
Date: Tue, 07 Feb 2012 19:47:19 +0200

> Date: Tue, 07 Feb 2012 19:30:51 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 4673 <at> debbugs.gnu.org
> 
> > Date: Tue, 7 Feb 2012 15:30:12 +0000
> > From: Richard Copley <rcopley <at> gmail.com>
> > Cc: 4673 <at> debbugs.gnu.org
> > 
> > I rebuilt from the patched sources, and (dired "//root/share") works
> > fine here now.
> 
> Thanks for testing, I will install the change soon.

Done (revision 107167 on the trunk).

Previous Next

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