Re: Extended attributes, Linux and GNOME

[Sean Middleditch <elanthis awesomeplay com>]

On Thu, 2003-04-03 at 17:59, Manuel Amador (Rudd-O) wrote:
> 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.

*if* they have a kernel that supports them.  RH8 doesn't  RH9 doesn't. 
Not distro I know of does.  No -STABLE release of FreeBSD does.  I doubt
any of the other BSD's do.  Just the people riding the bleeding edge of
Free OS's get these features.

And even if we supported them, relying on them is still bad.  You can't
back ACL's up with most tools available (Acl/ea support is just barely
starting to get into GNU userspace).

It wouldn't at all be bad to see *support* for these in GNOME, just not
*reliance* on them.  Even when free OS's do support these fully, you
still have tons of file-systems that can't handle them at all that GNOME
should be capable of working with.

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

Well, corrupt depends on pov I guess - if a tool changes some acl's on
my files and ends up granting different access... it may be technically
losing them, but my security/file-system will certainly *feel* corrupted
;-)

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

In other words, GNOME becomes some driving force that screws over its
users who suddenly find they lose metadata across backups or whatnot,
all for the goal of furthering a technology that's coming along just
fine as is... ?

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

That is a point - a single standard is nice for when it does become
feasible.

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

Except be reliable.  ;-)

> 
> luck,
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.