RFC: Extended Attribute Support for tar (wd)

[Robert Watson]

FYI.  I'm sure Tim would appreciate comments from those actively using (or 
thinking about using) extended attributes and their backup semantics.

Robert N M Watson

---------- Forwarded message ----------
Date: Sun, 19 Mar 2006 11:54:06 -0800
From: Tim Kientzle <kientzle at freebsd.org>
To: posix1e at freebsd.org
Cc: Jaakko Heinonen <jh at tinysofa.org>
Subject: RFC: Extended Attribute Support for tar

To the members of the POSIX.1e mailing list:

Jaakko Heinonen and I have developed the following
approach for storing extended attributes in
"pax extended format" (an extension of tar format)
archives.  This is implemented in libarchive-1.2.51
on <http://people.freebsd.org/~kientzle/libarchive>:

Background:  pax extended format supports a general
key/value mechanism in which keys and values are stored
as UTF8 strings separated by an '=' character.

Proposal:  POSIX-style extended attributes are stored
as separate pax attributes as follows:

The pax name is
   LIBARCHIVE.xattr.<namespace>.<extended attribute name>
(Rationale:  pax standard requires non-standard extensions
be prefixed with an all-uppercase vendor name.)
The extended attribute name (including namespace)
is encoded using URL-encoding  (specifically, '%'
becomes '%25', '=' becomes '%3D', and all non-ASCII
characters are similarly encoded).  (Rationale: The
encoding here avoids any problems from '=' characters
appearing in the extended attribute name.)  Note that
the result of URL-encoding will be ASCII and hence
already UTF-8.  (Note: ASCII names that do not contain
'%' or '=' appear in the archive exactly as they
appear in the filesystem.)

The value is base64 encoded (MIME encoding, except
without line breaks and the last group is not padded).
(Rationale:  extended attribute values are binary
and must not be modified; base64 encoding is widely
understood.)

   By default, "system" and "root" namespaces are not
archived.  (Rationale: These are often not accessible
to regular users.  They are often used for ACLs and
other properties that should be archived using other
mechanisms.)

Comparison with other approaches:  Joerg Shilling's
"star" implementation is the only "tar" program that I
know of that attempts to archive extended attributes.
It uses an approach similar to the above, but it
does not encode the attribute name (hence cannot
handle attributes with '=' or non-ASCII bytes in
the name) and stores the attribute value as raw
binary (which contradicts the pax specification
which requires UTF8).

Any comments or feedback are greatly appreciated.

Tim Kientzle
mailto:kientzle at freebsd.org


_______________________________________________
posix1e at FreeBSD.org mailing list
http://lists.freebsd.org/mailman/listinfo/posix1e
To unsubscribe, send any mail to "posix1e-unsubscribe at FreeBSD.org"