Re: Extended attributes, Linux and GNOME

["Manuel Amador (Rudd-O)" <amadorm usm edu ec>]

Sean Middleditch wrote:

> While I wholly agree that these could be an awesome thing for desktops,
> the problem is really a lack of full support.  No released stable Linux
> kernel has support, no vendor kernel has support.
This is stable and slated for 2.4.21 and 2.6, AFAIK.  Most distributions 
come with ACL support (RH8 springs to mind) out of the box, and as ACLs 
ride on top of EAs, you can be pretty sure that the distributions do 
have support for it.

>  And even then, most
> users won't have them.  Those that do, still have to contend with the
> fact that the GNU tools most of us have suck in that they can't support
> these extensions.
That is true.  At the very least:
* the GNU fileutils
* pax, cpio and tar
all of them need to bolt on support for EAs.  Other tools would be icing 
on the cake.

>  Also notice how a good deal of popular of software
> will lose/corrupt these attributes on files without modification.
I agree with you on losing the metadata.  But corrupting I'm not so 
sure, because they don't even notice it yet.

> Maybe once the user-space tools are more up-to-date, acl's/attr's are in
> more Linux released/user-used kernels, FreeBSD5 is more prevalent (it
> has acl/attr support in 5.0), etc. the Free Desktops can rely on these
> features in Free OS's (which commercial OS's have had for years, in many
> cases.)
see my comment below.

> One thing that would be nice *now* is at least ACL editing support in
> Nautilus for file-systems that support it. 
Agree 100%.  And the KDErs are biting this bullet right now.

> That's something that
> doesn't screw over users without, and greatly help users that have.  ^,^

To add a couple of comments:  I'm pretty sure that Nautilus and GNOME 
support for EAs is a good thing.  I'm also convinced that the time to 
support it is *now*, because that only would drive adoption of EAs 
further, and because our own metadata solution is crappy (come on, 
.nautilus-metafile.xml?) and will not ever be supported by standard GNU 
fileutils, whereas EAs might very probably be supported soon enough.  
The right way to do this, IMHO, is detecting for EA compatiibility and 
reverting to old metadata if no EA compat is detected.  This wouldn't 
make us lose functionality on platforms that don't support EAs.

The critical requirement here is that we agree with KDE or perhaps other 
DEs, via FreeDesktop.org communication channels, on a single 
specification for EA storage (emblems, comments on files, etcetera).  
Perhaps, since KDE is lagging Nautilus in this respect, GNOME people 
could draft the specification, write some code, and invite KDE to join 
us in this.

Trust me.  We can use EAs now.  There's nothing with the current 
metafile method that couldn't be done with an EAs ipmlementation.

luck,