[linux-cifs-client] review 5, was Re: projected date for mount.cifs to support DFS junction points

[Q (Igor Mammedov)]

On Wed, Mar 12, 2008 at 1:14 AM, Steve French <smfrench at gmail.com> wrote:

> After looking at the memleak in more detail - I am not convinced that
> we should be altering the path on all calls to QueryPathInfo when
> SMB_SHARE_IS_IN_DFS
>

SNIA CIFS-TR 1.0 spec:
3.6. DFS Pathnames
A DFS pathname adheres to the standard described in the FileNames section. A
DFS enabled
client accessing a DFS share should set the Flags2 bit 12 in all name based
SMB requests
indicating to the server that the enclosed pathname should be resolved in
the Distributed File
System namespace. The pathname should always have the full file name,
including the server
name and share name. If the server can resolve the DFS name to a piece of
local storage, the
local storage will be accessed. If the server determines that the DFS name
actually maps to a
different server share, the access to the name will fail with the 32-bit
status
STATUS_PATH_NOT_COVERED (0xC0000257), or DOS error ERRsrv/ERRbadpath.


> This seems excessive - only a small subset of the directories (or
> files) in a share which is in the DFS namespace would require a second
> lookup
>

In short words:
We must send full UNC to get error -EREMOTE because server
will return OK otherwise and we will get root share inode instead.
This error is the only way to get the knowledge whether it is dfs
path or not. That's why we send full path name when the tree is in
DFS (SMB_SHARE_IS_IN_DFS).

On the other hand: the second call to QueryPathInfo, when we already
know that the path is in DFS, is a questionable  matter.
I attempt to fill "future mount point" inode with data returned by
server for "link" path.  Theoreticaly we can fill it with some static values
here and avoid the second call. The question is "what values?"


>
> On Tue, Mar 11, 2008 at 4:41 AM, Q (Igor Mammedov)
> <qwerty0987654321 at mail.ru> wrote:
> > Mem leak fix in inode.c
> >
>
>
>
> --
> Thanks,
>
> Steve
>
-------------- next part --------------
HTML attachment scrubbed and removed