"Gordon Waidhofer" <gww@traakan.com> wrote:

> > 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.

Well, I believe that the main advantage of star over
other tar implementations is that I am the only author 
for the past 23 years. Other implementations suffer from the
fact that the authors/maintainers change frequently and there
is no knowledge about the intentions of the previous maintainers.

I am currently finishing the incremental backup/restore features
and the goals of the next release will be support for Sun's 
Extended Attribute files and a completely new path/tree traverssal
method that completely removes any path length limitations.

There is a high probability that pax from star will become /usr/bin/pax
for OpenSolaris and later replace Sun's tar too.


> 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 Files have been added after 
Microsoft did try to launch an attempt to include a strange 
implementation for this feature in POSIX. THey did like to 
make '...' special which would have made all find implementations
broken. My impression is that Sun did make this implementation just
to show that there is a decent way to implement the desired feature.

> 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.

It seems that a few people from the Trusted Solaris group know how and
already use this feature for security labels but I have not been able
to contact them altough it is easy to exchange mail with any Sun Kernel
developer. Most of them are on the OpenSolaris mailing list and I know
many of them personally.

Even Jeff Bonwick (the leader of the ZFS development) does not know
how Solaris Extended Attributes Files are used.

> 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().

First a note: I believe that we should try to add BSD file flags to
UFS and contact the ZFS team. After the 32 bit uid/gid transition is
complete on UFS, we have 2x16 bit free for file flags.

The big problem on Linux is that Linux implements ACLs inside
Linux Extended Attributes and star needs to exclude the 
Extended Attributes that carry ACL data.

I don't know how Linux getxattr() is implemented internally but Linux
file flags are broken by design. If you try to archive flags from
/dev/* you may kill the system.

On Solaris, I hope that the upcoming Community advisory Board will
make it easier to influence the future of Solaris. 


> 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.

Well, you could say that a Linux xatte BLA=hallo
could be mapped by creating a Solaris extended attribute file
"BLA" that has "hallo" as content. The difference I see is that
on Linux some of the "files" have a special system imposed meaning.


> 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.

Why and if so, how should NFSv4 deal with Linux xattrs?

> 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.
 
OK

> 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.

I don't know how to deal with ntfs but POSIX.1-2001
'x' data is infinitely extensible.

I hope that once ZFS appears inside the Solaris
developer sources and not only on Jeff Bowicks machine,
we will see support commands for MS denying ACLs.

ZFS will not come with zfsdump, so migrating incremental
backups to tar is needed and possible with star.

> 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.

What I like to do with star is to find a way that has a chance to
appear in a future POSIX. This means no fast decisions.
For this reason, I am still thinking about the best way to 
implement Solaris Extended Attribute files inside POSIX.1-2001
extensions.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily