FindFirst2 and DFS links

[Suresh Jayaraman]

On 03/04/2011 09:58 AM, Suresh Jayaraman wrote:
> On 03/04/2011 12:23 AM, George K Colley wrote:
>>
>> 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?
>>>
>>>
>> From a Windows Server you can, not sure what Samba does:
>>
>> /*
>> * Confirmed from MS:
>> * When the attribute has the Reparse Point bit set then the EASize
>> * contains the reparse tag info. This behavior is consistent for 
>> * Full, Both, FullId, or BothId query dir calls.  It will pack the 
>> * reparse tag into the EaSize value if ATTRIBUTE_REPARSE_POINT is set.  
>> * I verified with local MS Engineers, and they also checking to make 
>> * sure the behavior is covered in MS-FSA. 
> 
> Yeah, seems plausible to obtain the reparse tag via Easize by setting
> the info level to FIND_FILE_FULL_DIRECTORY_INFO (instead of
> FIND_FILE_DIRECTORY_INFO). I'll need to look at the packet capture from
> the Samba server too.
> 

I verified that the Samba server is setting the Reparse Point bit too.
Also, I could confirm from the packet traces that Windows is packing
reparse tag into the EaSize value if REPARSE_POINT File attribute is set
but, only when we ask for FULL_DIR_INFO (which might add little
overhead...?)

Thanks,

-- 
Suresh Jayaraman