xrootd: add stat request

[EgorMatirov]

Note that TestFile_FetchVirtualStatInfo is failing with an error: xrootd: error 3001: Required argument not present. I think that it's because it is called with handle instead of path (FileSystem calls it with path and it works correctly),

Can you take a look at specs for kXR_stat, please?
Especially:

Notes
...
4) kXR_stat - kXR_vfs requests need not specify an existing filesystem object. The specified path is used as a path prefix in order to filter out servers and partitions that could not be used to hold objects whose path starts with the specified path prefix.

I think that since there is no mention of handle it's not obvious that kXR_stat requires path to be passed and doesn't work when only handle is present.

Am I right? I'm a bit in doubt since I'm not very good at English and requests need not specify an existing filesystem object gives a hint that handle would not work.

I'll fill an issue if you too think that documentation is not clear on that topic.

[sbinet]

actually, before implementing kXR_stat, could you go with kXR_close?
I fear that we may crash the server with opening gazillions of files w/o closing them...

also, this will make other tests cleaner, spelling out the correct semantics like:

f, err := fs.Open(...)
if err != nil { ... }
defer f.Close()

[EgorMatirov]

Yep, I'll do.

[sbinet]

as for the specs, I agree that the fact that path is always required, even when one passes a handle, could be better phrased.

[sbinet]

not sure this function (nor the one below: NewRequestForHandle) actually improves the usability.

consider:

req := stat.NewRequestForPath("/foo/bar", false)
req := stat.Request{Path: "/foo/bar"}

or:

req := stat.NewRequestForPath("/foo/bar", true)
req := stat.Request{Path: "/foo/bar", Options: stat.OptionsVFS}

IMHO, it reads better using the named-struct-fields way :)

I would have probably gone with the NewXyz functions for forward compatibility in the event that stat.Request gained new Options or new fields (recouped from the [11]byte reserve), but the specs require that everything is zeroed, so new versions of Request would have to differ.

what do you think?

[EgorMatirov]

but the specs require that everything is zeroed

I got it this way: in the future, these zeroed values can be used for passing some parameters that will have zero as their default value.

Let's assume that some of the reserved values are changed to the meaningful parameter. Probably the default value (0) will be suitable for the most of cases, so backward compatibility will be kept.

I think that in most of the cases we will not want to change these default values (to keep backward compatibility from our side too). So, NewRequestForPath will not be modified and another func will be introduced.

From that point of view, it's ok to use Request{ ... } instead of NewRequestForXyz.

[sbinet]

while still waiting on an answer on xrootd/xrootd#728, could you please rebase and skip the failing test (but also adding a FIXME note that points to the xrootd/xrootd#728 issue) ?

thanks.

[sbinet]

LGTM