FindFirst2 and DFS links

[George K Colley]

On Mar 3, 2011, at 6:02 AM, Suresh Jayaraman 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?
> 
> 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?
> 
>