> >
> >  - How are getexattr etc. intended to be used, as the examples in the
> >    manpages do not work.
> 
> That's because the extattr bits have not been integrated into the FFS  
> code yet.  The VFS layer changes are present, but not the file system  
> layers.

The intentions for extended attributes should be reviewed.
If there is no real inertia here yet, that's a good thing.

A Linux-like getxattr() API should be used to interact
with new "true" attributes (ACLs, etc). The BSD-style
extattr_get...() interfaces should be deprecated.
The Linux getxattr() is really more like ioctl(). It
manipulates attributes based on a name but leaves
the actual on-disk representation details to the
underlying file system. Getxattr() can be implemented
at the library level as a wrapper around the BSD-style
extattr_get*(). There is momentum (like star) built
on getxattr().

"User attributes" (misnomer) should be done ala subfiles.
The Solaris model is best and, since openat() and friends
were put on the table within the last few months, perhaps
natural.

NFSv4 has a model for subfiles (extended attributes) that
pairs well with Solaris, NetApp, and NT. All are using
an opaque, file-like, arbitrary sized (think gigs),
read/write type thing. The BSD/Linux "user" extended
attributes are inadequate -- much too small. Can't
have NFSv4 interface with two different models, so might
as well go with the one that will ultimately prevail
(Solaris, NetApp, NT).

Subfile support would go a long way to improving
how well Samba works on NetBSD.

OS/2 HPFS long ago added user extended attributes
and they were soon found inadequate. Such is supported
as legacy by NT and SMB, but nobody I've talked to
has ever seen it actually used. Everything moved to
subfiles.

More details and references here:

      http://www.nasconf.com/pres04/waidhofer.pdf

Regards,
	-gww