ENOATTR vs ENODATA

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Hi

There is a choice to be made about returing ENOATTR or ENODATA  when we
do not find an extended attribute. 

Here are the existing behaviors:

1) return ENOATTR, while ENODATA is defined and has other usages: NetBSD
and MacOS X

2) return ENODATA, while ENOATTR is not defined: Linux

3) return ENOATTR, while ENODATA is not defined: FreeBSD

The problem is that some userland program may test (errno == ENODATA)
and get a different semantic on NetBSD and Linux. glusterfs does that,
for instance.

It seems there is no standard about this. OpenGroup only defines
ENODATA, but for another usage (STREAM). 

In order to get the broader compatibility, I suggest patching our
errno.h to define ENOATTR as ENODATA. Opinions?

Index: sys/errno.h
===================================================================
RCS file: /cvsroot/src/sys/sys/errno.h,v
retrieving revision 1.39
diff -U 4 -r1.39 errno.h
--- sys/errno.h 31 Oct 2006 00:38:07 -0000      1.39
+++ sys/errno.h 30 Apr 2012 09:17:43 -0000
@@ -164,9 +164,9 @@
 #define ENOSTR         91              /* Not a STREAM */
 #define ETIME          92              /* STREAM ioctl timeout */
 
 /* File system extended attribute errors */
-#define        ENOATTR         93              /* Attribute not found
*/
+#define        ENOATTR         ENODATA         /* Attribute not found
*/
 
 /* Realtime, XSI STREAMS option errors */
 #define        EMULTIHOP       94              /* Multihop attempted */
 #define        ENOLINK         95              /* Link has been severed
*/
 
 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost