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

[Igor Mammedov]

Jeremy Allison wrote:
> 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.

As I understand 'extensions', should not break interface
they are extending. Symlink for DFS junction point is
just the way chosen by samba for storing dfs metadata.
So showing it as directory isn't breaking 'posix' way
at all, just hides particular implementation details.

Also for compatibility with clients it would be better
to behave like MS even with "Unix Ext." turned on.
Working the same way in both modes for similar concepts
reduces headache for everyone.
 
> 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.

Typically client expects to see directory here.
MS uses another way for getting metadata for such dirs.
When I dig up how they do it, I'll try to write corresponding
code for cifs to show which referrals up/down/connected
for a dfs junction point.


> 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.

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!!!
Of cause it is possible to rewrite such 'symlink' in readdir
syscall handler, but is it the best way? 

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.

-- 

Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com