Subject: Extended Attributes (was RE: the undocumented FFS2 root trouble)
To: None <email@example.com>
From: Gordon Waidhofer <firstname.lastname@example.org>
Date: 04/25/2005 12:20:21
> > - 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
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
"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
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
More details and references here: