FindFirst2 and DFS links

[Steve French]

On Thu, Mar 3, 2011 at 8:02 AM, Suresh Jayaraman <sjayaraman at suse.de> wrote:

> Hi all,
>
> I'm looking into a CIFS client bug report where access to a DFS link
> fails with -EREMOTE error intermittently. Later accesses to the DFS link
> succeeds as dentry revalidation gets information about the DFS link.
>
> When the failure occurs, it appears that the Server (both Samba and
> Windows 2k8 server) returned -EREMOTE (NT_STATUS_PATH_NOT_COVERED) in
> response to the FindFirst2 call on the DFS link. Looking at the CIFS
> Spec, PATH_NOT_COVERED is not listed as one of the possible errors for
> FindFirst2. So it's not clear why the Server is sending the same.
>
> In order to handle this error, the CIFS client should find a way to
> figure out from the Server's FindFirst2 response that it is a DFS link.
> The only promising bit (in File attributes) is the "Reparse Point" which
> is set in the response from a Windows Server. However, the Reparse point
> could be something other than (symlinks or volume mountpoint etc) a DFS
> junction. Is there a way to clearly distinguish a DFS junction?
>
>
Yes - we have code to query a reparse point, but I doubt that is a good idea
here.


> In short:
>
> * Is there a way to identify a DFS junction from the FindFirst2
>  response?
> * Is NT_STATUS_PATH_NOT_COVERED error expected for a DFS junction in the
>  FindFirst2 response?
>
>
I don't see it in the corresponding section of MS-CIFS (2.2.6.2.2.2) as a
possible
return value but it seems plausible.   The lookup (querypathinfo) on
the root directory already should have generated the path not covered so it
could
be a server bug.   We may want to check if we create a cached inode for the
junction when we did a findfirst on the parent directory (ie there wasn't
ever
a QueryPathInfo on the DFS junction before the Findfirst on the DFS
junction) - if so we could avoid caching the metadata information in
findfirst response for those entries which a reparse point.

In any case - we need a wireshark trace so we can open a dochep
request to Microsoft on the important missing rc in MS-CIFS.



>
> cFYI snip (for the curious)
> ---------
>
>  fs/cifs/readdir.c: CIFS VFS: in cifs_readdir as Xid: 105 with uid: 0
>  fs/cifs/readdir.c: Full path: \\mydomain\dfsroot\dfslink start at: 2
>  fs/cifs/cifssmb.c: In FindFirst for \\mydomain\dfsroot\dfslink
>  fs/cifs/transport.c: For smb_command 50
>  fs/cifs/transport.c: Sending smb of length 142
>  fs/cifs/connect.c: rfc1002 length 0x27
>  fs/cifs/connect.c: invalid transact2 word count
> Status code returned 0xc0000257 NT_STATUS_PATH_NOT_COVERED
>  fs/cifs/netmisc.c:  !!Mapping smb error code 3 to POSIX err -66 !!
>  fs/cifs/cifssmb.c: Error in FindFirst = -66
>  fs/cifs/readdir.c: initiate cifs search rc -66
>  fs/cifs/readdir.c: CIFS VFS: leaving cifs_readdir (xid = 105) rc = -66
>  fs/cifs/file.c: Closedir inode = 0xd3f3acf0
>  fs/cifs/file.c: CIFS VFS: in cifs_closedir as Xid: 106 with uid: 0
>  fs/cifs/file.c: Freeing private data in close dir
>  fs/cifs/file.c: CIFS VFS: leaving cifs_closedir (xid = 106) rc = 0
>
>
> Thanks,
>
> --
> Suresh Jayaraman
>



-- 
Thanks,

Steve