Re: dfs path construction fixup for / character in \\server\share component of dfs path

["Steve French" <smfrench@gmail.com>]

On Fri, May 23, 2008 at 7:46 PM, Jeremy Allison <jra@samba.org> wrote:
> On Wed, May 21, 2008 at 05:57:48PM +0400, Igor Mammedov wrote:
>>
>> Magic is really sucks. Because of DFS junction point
>> is symlink in samba, when unix ext. is on, we had to do
>> that magic thing in the kernel code.
>> Now we have following behavior:
>> 1.  when client makes 'ls' for the first time on the
>>     directory with DFS links, 'ls' shows them as symlinks.
>> 2.  when we follow through a such 'symlink', it finely
>>     becomes a directory.
>> That magic!!!
>> IMHO:
>>   For a client the way better to see a directory from the start.
>>   (common code for handling this case for MS and Samba servers)
>>   and no magic at all.
>
> I can easily do this in the server, the problem is
> how we define what is "correct" from the client
> view with the UNIX extensions turned on.
>
> The problem is the Samba implementation
> is bleeding out onto the wire here. As we're
> stuck with it for the time being we have to
> make the best of it. Trouble is, I'm not
> sure what exactly the right decision is
> here..

I don't know what is best either ... but whatever we do we should be
careful not to hurt performance ... I would like to know what happens
on: readdir of a directory contains a DFS "symlink"  (followed by
lookup of the symink inode which is cached) followed by get sym link
info.  Does that return STATUS_PATH_NOT_COVERED and everything works
...?

-- 
Thanks,

Steve