On Wed, Mar 12, 2008 at 1:14 AM, Steve French <
smfrench@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?"
--
Thanks,
Steve