Re: Extended attributes, Linux and GNOME

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]