[linux-cifs-client] Re: dfs path construction fixup for / character
in \\server\share component of dfs path
Jeremy Allison
jra at samba.org
Mon Apr 28 18:05:26 GMT 2008
On Sun, Apr 27, 2008 at 05:00:20PM +0400, Igor Mammedov wrote:
> Jeremy Allison wrote:
> > On Thu, Apr 24, 2008 at 12:04:06PM +0400, Igor Mammedov wrote:
> >
> >> I'm doing the second call with a short path to get inode info
> >> including server generated inode number. If not for the last
> >> then second call could be omitted and inode be filled with fake
> >> values and locally generated ino.
> >>
> >> PS:
> >> Windows server does not object against the second call and returns
> >> info on the dfs junction point (as directory).
> >> More uniform behavior between different implementations would be
> >> better for all.
> >
> > Can you try this patch against the 3.2 code please. It should
> > cause smbd to return a directory on the short QFILEINFO call.
>
> Thanks for a patch, I've just tested it. Packets dumps are attached.
>
> Short summary:
> 1. unix extentions are disabled. Works.
> * ls on the directory that has a dfs link "dfs2" shows that it is directory
> * second QPATHINFO on "\dfs2" returns that it is directory (pkts 28-29)
>
> 2. unix extentions are enabled. Works partially.
> * ls on the directory that has a dfs link "dfs2" shows that it is a link
> (pkts 26-27). Would be nice if it was listed as directory here.
> * second QPATHINFO on "\dfs2" returns that it is directory (pkts 36-37)
>
> Traverse over DFS junction point now works in both both cases.
Can you send me the same packet trace against Windows please ? I need
to see exactly how Windows responds to the \dfs2 query with flags2
set.
Jeremy.
More information about the linux-cifs-client
mailing list