On Thu, 07 Jun 2007 16:33:00 -0600, Mark Shellenbaum wrote:
>Subject: Re: Extensible Attribute Interfaces [PSARC/2007/315 FastTrack timeout
06/06/2007]
>
>Don Cragun wrote:
>> The case materials say that this case will be allowing extensible
>> attributes to be added presumably by any vendor/application writer that
>> wants to add an attribute to a file. Discussion on this topic has
>> implied that there will be no registration of extensible attributes
>> because registration is complex, slow, etc. The case materials also
>> state that utilities, including ls(1), will be modified to display all
>> of the attributes associated with a file.
>>
>> Since there is no registration of attributes and none of the new
>> interfaces being added here provide a textual description of the
>> attributes, how is ls supposed to be able to display the attributes (at
>> least those that are not included in this case) in any manner that will
>> have any meaning to someone looking at the output from ls?
>>
>> Is it really going to help anyone if all ls can say is something like
>>
>> -rw-r--r-- (--SA--------) 1 dwc staff 5771 Jun 7 11:35 file
>> Unknown Attributes: 0x00647763:00000002, 0x00647763:00000008,
0x00647763:00000040, 0x00647763:00000800
>>
>> when it encounters unknown extensible attributes?
>>
>> - Don
>>
>
>
>Although this case allows for system attributes to be added, it
>does not presume that anyone can add any system attribute without
>ARC approval. As stated in an earlier e-mail to Glenn:
>
> Changes to support new system attributes will touch
> enough to justify PSARC attention.
This sort of works for "system" attributes. PSARC becomes the
registration authority for "system" extensible attributes, and any case
coming to PSARC for a new system attribute will have to include an
update to [at least] ls(1). It doesn't work for non-"system"
attributes.
>
>Also, please see section 4.4 Managing Change in the Attribute Space.
>
>As for displaying the attributes via 'ls', there is a separate
>effort by the Utilities Group to tackle this problem. There are
>two things that this project team can suggest:
>
>- Project teams that propose new system attributes are responsible
> for all aspects of those attributes. Including the decisions on
> whether or not they are set by a user-level API and whether or not
> they are displayed by ls(1) or any other utility.
>
> This project team cannot predict what future attributes will be
> proposed.
>
>- The Utilities Team may choose to take advantage of the nvpair
> format returned by fgetattr(). This will allow them to format
> and display (name and value) all available system attributes.
This case should be providing the basic infrastructure to enable
extensible attributes to be used correctly. It seems to me that this
project is incomplete for two reasons:
1. it doesn't provide a mechanism for extensible attributes to
identify themselves, and
2. it doesn't provide a registration mechanism for non-"system"
extensible attributes.
- Don
