Extended attribute interfaces

[Pat Dirks]

>On Fri, 7 Jul 2000, Robert Watson wrote:
>
>> While the numeric constant can and will be different on different
>> platforms, error message and constant name consistency is important.  Is
>
>I say this in a somewhat blase kind of way, but ignored the fact that in
>the FreeBSD world, we actually are interested in knowing (if not matching)
>the errno values from some other platforms, including Linux, for emulation
>purposes.  The FreeBSD ABI layer for Linux, iBSC2, and SVR4 compatibility,
>as well as NFS service, needs to know what mappings are made between
>BSD-side values and errno values from relevant platforms.  From your
>e-mail, it sounded like a value has not officially been assigned in the
>Linux community.  Do we know what process is involved there, and whether
>that will be completed in the next couple of weeks?
>
>  Robert N M Watson 

FWIW, Apple's Mac OS X has defined a few new errors in that range as 
well.  There's (quoting from our /usr/include/sys/errno.h:

/* Intelligent device errors */
#define EPWROFF         82      /* Device power is off */
#define EDEVERR         83      /* Device error, e.g. paper out */

#ifndef _POSIX_SOURCE
#define EOVERFLOW       84              /* Value too large to be stored 
in data type */

/* Program loading errors */
/* Program loading errors */
#define EBADEXEC        85      /* Bad executable */
#define EBADARCH        86      /* Bad CPU type in executable */
#define ESHLIBVERS      87      /* Shared library version mismatch */
#define EBADMACHO       88      /* Malformed Macho file */

#define ELAST           88              /* Must be equal largest errno */
#endif /* _POSIX_SOURCE */

... so 88 would be a better value if consistency across BSD 
implementations is a concern.

Mac OS X also includes its own new attribute interface to allow the 
retrieval of metadata not included in stat, such as HFS's backup date, 
object id, create time, finder info, directory entry count, and a host of 
other attributes.  I've been meaning to send a note describing the 
mechanism we're using; I have a feeling it's aimed at a slightly 
different kind of use but it does have some overlap with the extended 
attribute mechanism being proposed on this list.  The glaring difference 
is that the interface for specifying the attribute is bitmap-based 
instead of name-based.  I'll try to follow up with some details.  Since 
this API has a similar opening for requesting attributes that are not 
supported on a particular filesystem I'd been about to define an 
EUNKNOWNATTR myself.  I'll be happy to use a more general ENOATTR 
instead, as well.

Best regards,
-Pat Dirks,
Mac OS X Filesystems Tech Lead.
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message