Skip to contentSkip to conversation

Define ENOATTR in 2.5 kernels

PATCH In review Andreas Gruenbacher 2 participants 2 messages Aug 2, 2002

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Define ENOATTR in 2.5 kernels

Hello,

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>.

Regards,
Andreas.

------------------------------------------------------------------
Andreas Gruenbacher SuSE Linux AG
mailto:[email protected] Deutschherrnstr. 15-19
http://www.suse.de/ D-90429 Nuernberg, Germany

Add the ENOATTR error number ("No such attribute")

The ENOATTR error number is needed by the file system specific code that implements Extended Attributes. This error can occur when trying to retrieve, replace (XATTR_REPLACE flag) or delete an attribute that does not exist.

include/linux/errno.h renamed from include/linux/errno.h.orig +3 -0
@@ -11,6 +11,9 @@
 #define ERESTARTNOHAND	514	/* restart if no handler.. */
 #define ENOIOCTLCMD	515	/* No ioctl command */
 
+/* Extended Attributes */
+#define ENOATTR		516	/* No such attribute */
+
 /* Defined for the NFSv3 protocol */
 #define EBADHANDLE	521	/* Illegal NFS file handle */
 #define ENOTSYNC	522	/* Update synchronization mismatch */
sysdeps/gnu/errlist.c renamed from sysdeps/gnu/errlist.c.orig +8 -0
@@ -607,6 +607,14 @@
 TRANS for information on process groups and these signals. */
     [ERR_REMAP (EBACKGROUND)] = N_("Inappropriate operation for background process"),
 #endif
+#ifdef ENOATTR
+/*
+TRANS No such attribute.  The named Extended Attribute does not exist, or the
+TRANS process does not have permission to access the attribute. This error
+TRANS is used by the getxattr, setxattr and removexattr system calls.
+TRANS */
+    [ERR_REMAP (ENOATTR)] = N_("No such attribute"),
+#endif
 #ifdef EDIED
 /*
 TRANS In the GNU system, opening a file returns this error when the file is
#1 lore raw
Quoted 10 lines · Andreas Gruenbacher

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.

Quoted 7 lines

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
[email protected] Network Associates Laboratories