[linux-cifs-client] Re: dfs path construction fixup for / character
in \\server\share component of dfs path
smfrench at gmail.com
Sat May 24 01:33:32 GMT 2008
On Fri, May 23, 2008 at 7:46 PM, Jeremy Allison <jra at 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!!!
>> 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
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
More information about the linux-cifs-client