RFC: Extended Attribute Support for tar

[Robert Watson]

On Mon, 20 Mar 2006, Tim Kientzle wrote:

> Robert Watson wrote:
>> On Sun, 19 Mar 2006, Tim Kientzle wrote:
>> 
>>>  By default, "system" and "root" namespaces are not archived. 
>> 
>> This all sounds pretty reasonable to me, especially the decision regarding 
>> system attributes.  Since you say "by default", I assume you intend to 
>> provide a way to optionally backup and restore attributes in other name 
>> spaces if requested?
>
> I'm trying to figure that part out.  For example, I'm wary of backing up 
> FreeBSD ACL information in two different forms (as ACL and as extended 
> attribute).  I seem to have read that XFS uses the "root" namespace for 
> filesystem private info that should not be backed up and restored, much less 
> copied across systems.
>
> Are there any conventions about these namespaces?

My understanding is pretty much yours -- the FreeBSD system/user model is very 
much modeled on the IRIX model, in which one name space is intended for kernel 
components to access, supporting a variety of semantic-rich attributes, and 
the other is for opaque data stored by applications.  In that view of the 
world, you want to back up attributes using the defined APIs, which among 
other things, have something to say about returning the data in portable 
formats (i.e., converting the ACL to portable text).  However, it would be 
useful to be able to request the backup and restore of specific system 
attributes by name for situations where there may not be a portable API -- 
i.e., if there's a kernel component storing MD5 checksums of executables in 
the system name space, it would be nice to be able to request they be backed 
up and restored with the files.

Robert N M Watson