From owner-freebsd-fs@FreeBSD.ORG Mon Mar 20 19:18:27 2006 Return-Path: X-Original-To: fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D45116A41F for ; Mon, 20 Mar 2006 19:18:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 845E943D4C for ; Mon, 20 Mar 2006 19:18:26 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 944F446BE9 for ; Mon, 20 Mar 2006 14:18:25 -0500 (EST) Date: Mon, 20 Mar 2006 19:18:25 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: fs@FreeBSD.org Message-ID: <20060320191736.K67379@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: RFC: Extended Attribute Support for tar (wd) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2006 19:18:27 -0000 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 To: posix1e@freebsd.org Cc: Jaakko Heinonen 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 : 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.. (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@freebsd.org _______________________________________________ posix1e@FreeBSD.org mailing list http://lists.freebsd.org/mailman/listinfo/posix1e To unsubscribe, send any mail to "posix1e-unsubscribe@FreeBSD.org"