> (snip)
> I was looking for a person to discuss xattr issues and did not find 
> interested people. Even Jeff Bonwick (the main author for ZFS) 
> did have a long discussion (*) about many important ZFS features
> but did not help with Linux xattr vs. Solaris extended
> Attribute files.
>
> (snip)
> 
> For Linux xattr: I would like to see a definition framework that allows
> to implement Linux xattrs inside Solaris extended Attribute files.
>

These issues aren't just brewing. They are looming.

Star represents a great deal of research and address.
I'm told that the Samba folks are starting to ask
for subfile (stream) support because more and more
uses of streams are showing up in MS apps, further
hardening the link between MS apps and NTFS. UNIX
file systems have to evolve to maintain interoperability.

Solaris Extended Attributes were done to support NFSv4
development. NFSv4 has Named Attributes. Both were commenced
before they were really understood. Both Solaris Extended
Attributes and NFSv4 Named Attributes are really subfiles,
sometimes called named streams.

BSD/Linux/OS2/etc Extended Attributes (xattrs) are
very different. They really are for additional file
attributes (ACLs, security labels, integrity labels,
encryption keys, etc, etc, etc). The best interface
is Linux getxattr(), which really can be thought of
like ioctl().

The big mistake folks make is thinking the Solaris/NFSv4
thing and the BSD/Linux thing are the same. They
are entirely different animals with the (unfortunately)
same name. Indeed, Solaris/NFSv4 is what is misnamed.

I think implementing Linux xattrs inside Solaris
Extended Attributes is a bad idea. I recently participated
in a discussion on the NFSv4 reflector and said the
same thing. There are others who recognize the unspoken
discord between Solaris/NFSv4 Extended Attributes and
Linux/BSD xattrs. I've lobbied hard to keep NFSv4
Named Attributes from being linked to Linux/BSD xattrs.
Better to do nothing that the wrong thing.

I agree that this topic probably belongs on another
mail list. Joerg, I would be quite happy to continue
this discussion off list if you like.

For everybody else.... star is a very nice program
that already researched these issues. It supports
"fancy features" on a variety of operating systems
and strives for interoperability. That's why I say
it supports and *facilitates* convergence. Star is
-- no pun intended -- a star to steer buy for all
the UN*Xes, Solaris included, to converge as driving
forces (i.e. NTFS) compell us to undertake these
fancy file features.

Last comment: it is entirely necessary that fancy
file features, NFSv4, and "tar" issues be contemplated
in concert. If I move a file tree via NFS using
cp -r -@, I want the same results as if I make a
tarball on the source system then burst it on the
destination system. I put them in a big tent
called interchange.

Regards,
	-gww