[linux-cifs-client] Re: dfs path construction fixup for / character in \\server\share component of dfs path

[Jeremy Allison]

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.

Ok, I just had a long chat with Volker about this and he made
some good points.

With unix extensions enabled doing a QPATHINFO or FINDFIRST
with a UNIX info level on /server/share/dfs/path always
returns PATH_NOT_COVERED, as it should.

Doing a QPATHINFO or FINDFIRST on /dfs/path with a UNIX info
level currently returns symlink, which exposes the Samba
implementation of the junction. For a Windows info level
it returns BAD_PATH, which is a bug in the Samba server
and part of my patch trivially fixes this.

The question I'm pondoring is - is it correct to spoof
this to show a directory when you are querying with a
UNIX info level ? On the positive side it hides the
Samba implementations. On the negative side it makes
it impossible to write code that actually allows the
client to see what is really on disk.

This goes against the spirit of the UNIX extensions,
which is to show straight "posix" on the wire. Now
we are in somewhat unknown territory, in that we're
defining the interface between UNIX extensions and
MSDFS, but if I spoof to show a directory when it's
really a symlink I'm lying to clients.

If I do the spoof there's no way for clients that
want to see the symlink (maybe in order to change
it) to do so.

I could add some "magic foo" and show the symlink
if the QPATHINFO request flags2 doesn't contain the
DFS_PATH bit, and show as a directory if it does,
but this sucks (and I hate magic foo such as this).

I'm inclined as Volker suggested to leave the current
behavior with UNIX extensions alone, as the client
knows it's dealing with a DFS path (after all the
first call got PATH_NOT_COVERED) and it allows the
client to code around the discrepancy (as you say
traverse over DFS junctions now works with the client)
but still allows the UNIX extensions to show what
is really on disk in full POSIX glory :-).

Steve, others, please comment !

Cheers,

	Jeremy.