There is quite a bit of discord about what
model to follow for extended attributes.
This is no small matter to NFSv4 folks who
are trying to decide how to support "Named
Attributes".

Utlimately, I believe NFSv4 Named Attributes
will correspond to subfiles (named streams)
ala NTFS. NetApp, Solaris, and the folks working
on NFSv4 for NT seem to agree.

The other model for extended attributes is
the OS2/Linux/BSD model, which I call xattr
for short. OS2 HPFS has a history of the so
called "user" xattr, which shows historically
that these are poor man's subfiles and quickly
found to be inadequate. However, the getxattr()
interface (think of it like ioctl() rather than
read/write) is much better than the BSD-style
extattr() interface. Indeed, Linux has gone to
manipulating all new attributes, including
POSIX ACLs, exclusively through the getxattr().
This includes the section 2 system interfaces
and the internal VFS interfaces.

There is some lobbying from the Samba folks
to support subfiles. The story I heard was
a good one, but I'll skip it for now.

The upshot is that I certainly support Solaris
style subfiles. They aren't really "attributes".
I strongly recommend renaming them to reflect
their ultimate role as subfiles (opensf rather
than openat).

A fair bit of prudence is advisable. The Solaris
interfaces are extremely experimentals. NFSv4
is still sorting it out, especially the access
control model. NTFS is like to address subfile
access control and it's best to avoid radical
divergence.

The star(1) archiver represents a lot of research
and address of new fangled attributes and interchange
between systems.

More here:

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

Regards,
	-gww


> -----Original Message-----
> From: tech-kern-owner@NetBSD.org [mailto:tech-kern-owner@NetBSD.org]On
> Behalf Of steinarh@pvv.ntnu.no
> Sent: Tuesday, March 01, 2005 12:36 PM
> To: tech-kern@NetBSD.org
> Subject: openat(2) and friends
> 
> 
> 
> 
> Solaris (since 9?), has some useful calls I'd like to have
> available on NetBSD too:
> 
> fchownat(2)
> fstatat(2)
> futimesat(2)
> openat(2)
> renameat(2)
> unlinkat(2)
> fdopendir(3)
> 
> All interfaces take both a file descriptor and a pathname as arguments,
> and have a "flag" argument:
> 
> int fchownat(int fildes, const char *path, uid_t owner, gid_t 
> group, int flag);
> int futimesat(int fildes, const char *path, const struct timeval 
> times[2]);
> int fstatat(int fildes, const char *path, struct stat *buf, int flag);
> int openat(int fildes, const char *path, int oflag, /*mode_t mode*/ ...);
> int renameat(int fromfd, const char *old, int tofd, const char *new);
> int unlinkat(int dirfd, const char *path, int flag);
> 
> The basic point is that a relative path is traversed from a file
> descriptor (refering to a open directory), instead of from the current
> directory.  This is very useful when traversing a untrusted directory
> tree.
> 
> If fildes is some special value AT_FDCWD, fstatat degenerates to stat,
> and if path is NULL, it degenerates to fstat. filedes=AT_FDCWD and
> flag&AT_SYMLNK_NOFOLLOW makes lstat.
> 
> Also, these calls will be needed for Solaris emulation.
> 
> fts(3) can take great advantage from the combination of openat(2) and
> fdopendir(3), and will no longer need to use chdir(2).
> 
> fdopendir(3) is simply a opendir-from-fd:
> 
> DIR *fdopendir(int fildes);
> 
> I tried implementing the exact same ting as fdopendir a few years ago,
> but ran into problems with NFS (and union mounts?). I beleve an openat
> that supports path=NULL would make this much easier. (It seems Solaris
> does not support path=NULL for openat.)
> 
> So, how does this sound? Are anyone eager to do this, or import it if
> I manage to make some patches?
> 
>         Steinar
>