bug#4673: Not the same as 4674

[Richard Copley <rcopley@gmail.com>]

On 3 February 2012 11:18, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 31 Jan 2012 11:51:27 +0000
>> From: Richard Copley <rcopley@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.