On Sep 6, 2005, at 11:29 AM, Gordon Waidhofer wrote:

> No. I'm not. But that's a common first reaction. The notion
> that BSD extended attributes suffice as subfiles is a dead
> giveaway that there is hardship confusion in the midst.

This discussion is about ACLs, not about the method by which the ACLs  
are stored.  You can store them in extattrs, you can store them in  
subfiles (I prefer the term "named forks", myself :-), I don't care  
(actually, I do care --- extattrs are much better for things like  
ACLs, because they are clearly defined as "attributes", whereas  
subfiles are in a grey area between "attributes" and "data").

Let's not beat the extattr horse any further... we can (and will)  
have extattrs, and we can (and will) have named forks^W^Wsubfiles  
(eventually).  I know of at least one file system in heavy use out  
there in the world that has both, and I see no reason why the two  
things are incompatible.

> Subfiles are accesses with read/write, can be arbitrary size
> (perhaps have holes), and contain opaque data (application
> meaningless to kernel and over-the-wire protocols). So too
> are the NFSv4 Named Attributes (that's the misnomer). BSD/Linux
> named "thingies" are accessed with get/set interfaces and are
> quite small.

Yes, I think we all understand the difference.

> Yes, the BSD/Linux named thingies may be useful internally
> to attach non-opaque (meaningful to kernel and over-the-wire
> protocols) attributes to a file (like ACLs). But they are
> completely useless for userland data. And you can't have both
> subfiles and named thingies coexist.

Nonsense!  The two can co-exist quite well together, and as I already  
stated, there is a production file system out there in the world that  
supports both simultaneously.

-- thorpej