[protocol specification] kXR_stat#fhandle is undocumented

[paulmillar]

The documentation for the kXR_stat request is missing any description of the fhandle request argument.

The most important parts are:

• is fhandle the handle returned from an kXR_open request, that has not yet been closed?
• when should the server react to the path fields (plen / path) and when it should react to fhandle?
• how should the server react if both are supplied?

[abh3]

Hi Paul, Correct that was introduced in 3.0.0 but that isn't the problem. It seems, like Brian points out, the client expects stat information to be returned with the open (it shouldn't and we are checking on this). Since dCache never returns stat information on the open, as far as I know, the client gets confused and ges into a recovery mode that, in itself, is faulty. So, there is no reason to finger-point dCache. Let us figure out of the fault lies with the client. Andy

…

On Wed, 10 Oct 2018, Paul Millar wrote: The documentation for the [kXR_stat request](http://xrootd.org/doc/prod/XRdv299.htm#_Toc337053399) is missing any description of the `fhandle` request argument. The most important parts are: * is fhandle the handle returned from an kXR_open request, that has not yet been closed? * when should the server react to the path fields (`plen` / `path`) and when it should react to `fhandle`? * how should the server react if both are supplied? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #839

[paulmillar]

Hi Andy,

Thanks for the comments, although I think you misunderstood the focus of this issue.

I'm referring to the PROTOCOL DOCUMENTATION, not about any client implementation or server implementation (i.e., this is NOT about code).

In v2.9.9 (linked to above) the PROTOCOL DOCUMENTATION does not describe what fhandle means, when describing the kXR_stat request. The field appears in the request structure, but is not described in the Where: section.

The same problem exists in the v3.1.0 and v4.0.0 of the PROTOCOL DOCUMENTATION: none of these versions describe what fhandle means for the kXR_stat request.

From reading the xrootd source code, I believe fhandle is an opened file handle (as returned by kXR_open). Also, if the client makes an kXR_stat request and specifies the plen value of zero then the server should use the fhandle value; otherwise, the path information (plen / path) is used.

It would be helpful if these details where checked, and the PROTOCOL DOCUMENTATION is updated to record this information, if they are correct.

Cheers,

Paul.

[xrootd-dev]

Hi Paul, You are absolutely right! I'm suprised the GO people didn't complain and they caught even minor issues. I will correct the docs. The fhandle is the open() request file handle. Sorry about the confusion. Andy

…

On Wed, 10 Oct 2018, Paul Millar wrote: Hi Andy, Thanks for the comments, although I think you misunderstood the focus of this issue. I'm referring to the PROTOCOL DOCUMENTATION, not about any client implementation or server implementation (i.e., this is NOT about code). In v2.9.9 (linked to above) the PROTOCOL DOCUMENTATION does not describe what `fhandle` means, when describing the `kXR_stat` request. The field appears in the request structure, but is not described in the `Where:` section. The same problem exists in the [v3.1.0](http://xrootd.org/doc/dev45/XRdv310.htm#_Toc464248850) and [v4.0.0](http://xrootd.org/doc/dev49/XRdv400.htm#_Toc517297887) of the PROTOCOL DOCUMENTATION: none of these versions describe what `fhandle` means for the `kXR_stat` request. > From reading the xrootd source code, I believe `fhandle` is an opened file handle (as returned by kXR_open). Also, if the client makes an kXR_stat request and specifies the `plen` value of zero then the server should use the `fhandle` value; otherwise, the path information (`plen` / `path`) is used. It would be helpful if these details where checked, and the PROTOCOL DOCUMENTATION is updated to record this information, if they are correct. Cheers, Paul. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #839 (comment) ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[abh3]

This has been fixed in the R5 documentation set.