 |
 |
Hi Andy, I don't really understand your comment about backwards compatibility. `kXR_mkpath` is defined as `256` ([defn](https://github.com/xrootd/xrootd/blob/master/src/XProtocol/XProtocol.hh#L222)). However, the `options` field of the `kXR_mkdir` command is only 8-bit wide, so cannot hold this flag. In fact, the SLAC xrootd implementation uses the undocumented `kXR_mkdirpath` flag ([defn](https://github.com/xrootd/xrootd/blob/master/src/XProtocol/XProtocol.hh#L161)). > As for dCache, you should follow the spec not the implementation. That is, indeed, our goal. Our problem is that the SLAC xrootd does not follow the xrootd specification and we have users that depend on dCache behaving like SLAC xrood implementation. My proposed solution is simple: update the documentation to accurately describe the SLAC xrootd software behaviour. This simply means changing the label `kXR_mkpath` to `kXR_mkdirpath` when describing the `kXR_mkdir` command. Do you have an estimate when the protocol document will be updated? -- 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/815#issuecomment-420962527 ######################################################################## 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