On Fri, 2 Aug 2002, Andreas Gruenbacher wrote:
> we already have a number of Extended Attribute system calls (*xattr) in
> the 2.5.x kernel. For implement them on file systems we also need the
> ENOATTR error. It makes little sense to reuse an existing error number
> as glibc's strerror() wouldn't be able to create an intelligent text
> message.
>
> ENOATTR also exists on Irix and AIX. Error messages for ENOATTR should
> be added to glibc once ENOATTR is defined in the kernel. I have attached
> a patch against glibc that adds the English error text.
>
> In addition to ENOATTR we also need to clarify the ENOTSUP / EOPNOTSUPP
> / ENOTSUPP issue, which I have posted yesterday (with no comments so
> far).
>
> For details concerning the xattr system calls you may find the manual
> pages interesting, which are available as part of the attr-devel
> package, and online at <http://acl.bestbits.at/man/man.shtml>.
FreeBSD 5.0-RELEASE, recent OpenBSD, and future Darwin/Mac OS X will use
ENOATTR in the following formulation listed in errno(2):
87 ENOATTR Attribute not found. The specified extended attribute does
not exist.
The English language text for ENOATTR generated by libc for strerror(3)
and friends is "Attribute not found".
ENOATTR will be returned when a read attempt is performed on an extended
attribute (namespace, name) that is not defined for the specified object.
Currently these systems use EOPNOTSUPP to indicate that the extended
attribute service is not available for the specified target object. I
believe that all of these systems define ENOTSUP as EOPNOTSUPP:
sproing:~> grep EOPNOT /usr/include/errno.h
#define EOPNOTSUPP 45 /* Operation not supported */
#define ENOTSUP EOPNOTSUPP /* Operation not supported */
In general, BSD VFS's return EOPNOTSUPP when VFS or vnode operations
attempted on an object are not defined/supported for the file system.
Other errors may take precedent over EOPNOTSUPP--for example, you might
get EISDIR if you attempt a file operation on a directory yet do it on a
file system that doesn't support the file operation, since that syntactic
check is performed at a higher level in the file system code.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:20 EST