Re: extended attributes and lsextattr/extattr_list_file

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

YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost> wrote:

> i strongly object against being api incompatible with freebsd for this.

Do we have any working program written out of there that are written to
use the  extattr_list_(file|link|fd) system calls we got from FreeBSD
(using <sys/extattr.h>? I expect most if not all third party programs to
use the Linux-like [fl]listxattr from <sys/xatttr.h>

And IMO, extattr_list_(file|link|fd) has a design drawback compared to
[fl]listxattr. Its way of prepending a one byte length for attribute
name limits forever the maximum length of attribute names to 255. Or
perhaps this is just a bug, since the documentation does not tell about
this prepended one byte length. The funny thing is that glusterfs has a
code section for FreeBSD that uses extattr_list_link(), but it assumes
the behavior from the documentation and is therefore broken with the
original extattr_list_link() implementation.

But if you have programs that depends on this oddity, we could modify
extattr_list_(file|link|fd) again to add it there. Do you have any real
world example that needs it?

> IMO linux-compatible api should have been in compat_linux.
> (and libc if desirable)

compat_linux is for ABI compatibility, not API compatibility. The
linux-like extended attribute API really needs to be implemented in
kernel or libc if you want to be able to build a program that uses
[fl](get|set|list|rm)xattr from <sys/xatttr.h>.

I considered doing it in libc, but [fl]setxattr() has XATTR_REPLACE and
XATTR_CREATE that requires an atomic test and set. It cannot be done
properly in libc and really needs to be done in kernel. Moreover, the
[fl](get|set|list|rm)xattr system calls have been available for a while
in the NetBSD kernel, so this was a minimal change.

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