Motivation
To quote errno.h comment on ENOSYS /*Invalid system call number"*/
> This error code is special: arch syscall entry code will return
> -ENOSYS if users try to call a syscall that doesn't exist. To keep
> failures of syscalls that really do exist distinguishable from
> failures due to attempts to use a nonexistent syscall, syscall
> implementations should refrain from returning -ENOSYS.
There are many reasons for the server to respond kXR_Unsupported, most of them not reasonably comparable to ENOSYS.
Some systems, like FUSE, treat ENOSYS very differently from other errors.
For example, when OPEN returns ENOSYS, it's considered a success (probably intended for cases where a filesystem does not need to implement an open syscall to work).
When xrootdfs OPEN fails because the server returned kXR_Unsupported because it does not support a specific set of open flags,
it is an error and should be treated as such. The file is not ready to be used after this open.
When FUSE requests an extended attribute and the server responds kXR_Unsupported, meaning that a particular xrootd query is not supported,
FUSE interprets it as a missing getxattr syscall and never tries to call getxattr again, even for the supported attributes.
In conclusion, FUSE shows that ENOSYS has a specific meaning and can't work as a mapping of kXR_Unsupported.
Why not use ENOTSUP instead?
Change: map kXR_Unsupported to ENOTSUP when interpreting protocol responses into error codes.
Result:
Will make dealing with kXR_Usupported errors easier and more predictable.
Should not break anything in xrootd code. The following was checked:
Errno is only compared to ENOSYS is oss, not on the network side where it can expect kXR_Unsupported to be ENOSYS.
Errno is never compared to EOPNOTSUPP.
Errno is only compared to ENOTSUP in:
* XrdFrmAdmin::Chksum, comparison for logging only
* XrdFrmAdmin::ChksumList, interrupt printing checksums if error is not ESTALE or ENOTSUP. The change makes sense in this context and should not break this.
* XrdFrmAdmin::ChksumPrint, logging
* XrdFrmAdmin::ConvTest, logging
* XrdFrmConfig::Configure
* looks like filesystem-side, not protocol-side?
* if it *is* network-side, makes sense to interpret kXR_Unsupported as ENOTSUP in this context
* XrdOfsFile::open
// Create the file. If ENOTSUP is returned, promote the creation to
// the subsequent open. This is to accomodate proxy support.
if it *is* networks-side, makes sense to interpret kXR_Unsupported as ENOTSUP
* XrdSysXAttr::Copy
* called from XrdOssCopy::Copy
* if it *is* network-side, makes sense to interpret kXR_Unsupported as ENOTSUP
You can view, comment on, or merge this pull request online at:
https://github.com/xrootd/xrootd/pull/516
-- Commit Summary --
* xrdposix: interpret kXR_Unsupported as ENOTSUP instead of ENOSYS
-- File Changes --
M src/XProtocol/XProtocol.hh (2)
-- Patch Links --
https://github.com/xrootd/xrootd/pull/516.patch
https://github.com/xrootd/xrootd/pull/516.diff
--
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/pull/516
########################################################################
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
