bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Define ENOATTR in 2.5 kernels


From: Robert Watson
Subject: Re: [PATCH] Define ENOATTR in 2.5 kernels
Date: Fri, 2 Aug 2002 13:48:44 -0400 (EDT)

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
address@hidden      Network Associates Laboratories





reply via email to

[Prev in Thread] Current Thread [Next in Thread]