I got a question regarding the XRootd Protocol Specification version 300 It specifies the kXR_dirlist request format as:
kXR_char streamid[2]
kXR_unt16 kXR_dirlist
kXR_char reserved[15]
kXR_char plen
kXR_int32 options
kXR_char path[plen]
while the Xrootd Protocol Specification version 299 lists the request format as:
kXR_char streamid[2]
kXR_unt16 kXR_dirlist
kXR_char reserved[16]
kXR_int32 plen
kXR_char path[plen]
The motivation for the change is clearly the addition of an options field, however the two records as documented in the specification are incompatible Note how the path length field in 299 is at offset 20 and is 4 bytes long, while in 300 is is at offset 19 and 1 byte long
Is this a bug in the specification or is this indeed the intended format? If so, does that mean that xrootd 300 (the protocol) is limited to paths shorter than 255 bytes, and how is a server to provide backwards compatibility with older clients?
—
Reply to this email directly or view it on GitHub.
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