Print

Print


The protocol spec does not, in many isntance, require that a server 
implement the corresponding action and leaves it unspecified what the 
server does when an unsupported flag is set. As I said, these flags are 
defined so that should a server wish to support the feature that is the 
flag that must be used. I see tat we both have dug in our heels on this 
one. You say if it's defined it has to do something and I say f it's 
defined but not supported it should not do anythng eveil but it need not 
do anything useful either. The mistake here is exposing it in the client 
API which, arguably, would seem to imply it actually does something.

I suppose we could make the server check but then we would need to do this 
in many other places as we have defined flags that are not (yet) 
supported. The current approach has been like this for some 20 years with 
no complaints. So, why all of a sudden is this a real issue?


On Thu, 30 Jan 2020, murrayc3 wrote:

> Looking at the following XRootD protocol code I can see that there is a protocol flag for each desired type of open including read:
>
> [itctabuild02] xrdcl_tests (master) > vi /usr/include/xrootd/XProtocol/XProtocol.hh
> ...
> enum XOpenRequestOption {
>   kXR_compress = 1,      // also locate (return unique hosts)
>   kXR_delete   = 2,
>   kXR_force    = 4,
>   kXR_new      = 8,
>   kXR_open_read= 16,
>   kXR_open_updt= 32,
>   kXR_async    = 64,
>   kXR_refresh  = 128,   // also locate
>   kXR_mkpath   = 256,
>   kXR_prefname = 256,   // only locate
>   kXR_open_apnd= 512,
>   kXR_retstat  = 1024,
>   kXR_replica  = 2048,
>   kXR_posc     = 4096,
>   kXR_nowait   = 8192,  // also locate
>   kXR_seqio    =16384,
>   kXR_open_wrto=32768
> };
>
> In other words read on the wire is not represented by a 0 and from what I can tell 0 means nothing/none.  Would you not be able to modify the XRootD server code to return an error to the client when there are leftover flags that its translation logic has not translated/consumed?
>
> -- 
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1126#issuecomment-580242921


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/1126#issuecomment-580488851

########################################################################
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