Supporting arbitrary file attributes

[Mike Gerdts]

A common problem with each vendor's version of tar is that it is unable
to support things like ACL's, extended attributes, etc. effectively. 
Furthermore, if one vendor comes up with a solution for the problem and
an analagous structure exists on another vendor's platform, there is no
guarantee that the information can be transported via a tar, cpio, or
any other known cross-platform utility.

I propose the following change as a potential change to a new GNU tar
extension that could address this problem.


1) Assign a new value to typeflag in posix_header that specifies GNU tar
extension type 2.  I suggest the value of the typeflag to be 'E',
mnemomic for "extensible".

2) 1 or more headers MUST follow the POSIX header.  Each header will
have the format:

    struct extensible_header
    {
        char magic[20];         /* descriptive name */
        char size[12];          /* size in bytes of this header */
        char *data;             /* the data in this header */
    };

A simple example of a specialized extensible header would be the
following:

    struct longpath_extensible_header
    {
        char magic[20] = "longpath"; /* right pad with NULL */
        char size[12] = "1036";
        char *path = "/some/long/path"; /* really 1024 characters */
    }

The intention is that the path value could be any length and would
override the name specified in posix_header for name and prefix.  If the
long path is only 300 characters, the size value would be 332.  It would
probably be a good idea to end on 32-bit boundaries (though not entirely
necessary?) so path should be able to be padded with null characters. 
(Are there any OS's out there that allow null characters in path names?)

A slightly more complicated example would be to store Solaris Access
Control Lists (ACLs).  Since these are quite similar (the same?) as
those implemented on HP-UX, and those that are emerging on various Linux
file systems, this could be a real boon to cross-platform portability of
files.  An Access Control List (ACL) is made up of one or more Access
Control Entries (ACE).

    struct acl_extensible_header
    {
        char magic[20] = "acl";
        char size[12];
        char ace_count[8];      /* number of ACEs below */
        struct acl_ace[];       /* the access control entries */
    }

With acl_ace defined along the lines of 

    struct acl_ace
    {
        char type[12];          /* type, see <sys/acl.h> */
        char id[8];             /* numeric UID or GID */
        char name[32];          /* user or group name */
        char mode[8];           /* similar to mode in posix header */
    }

To flag that there are no more extensions (and the file data follows),
the a header with magic "file_data" and length 32 (data is null) will be
used.

Tar implementations that are aware of this extensible header format that
do not support a particulare extensible feature should emit a warning
when the attributes cannot be assigned to the file.  For example, a file
association saved from a Windows file system will likely not be able to
be represented on a Solaris UFS file system and extraction should yield
a warning.

It would be feasible for different implementations to support a plugin
scheme as well.  Thus, a third party could distribute plugin modules
that allow tar to be arbitrarily extended tar's ability to create and
restore archives that need more sophistication than standard file I/O. 
For example, a mail spool plugin could handle locking of mail files
during backup and restore.  It may or may not add a special header.

Any thoughts?  Am I describing a free utility that already exists?

Mike