[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Supporting arbitrary file attributes
From: |
Mike Gerdts |
Subject: |
Supporting arbitrary file attributes |
Date: |
30 Mar 2002 23:32:59 -0500 |
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
- Supporting arbitrary file attributes,
Mike Gerdts <=
- Re: Supporting arbitrary file attributes, Joerg Schilling, 2002/03/31
- Re: Supporting arbitrary file attributes, Joerg Schilling, 2002/03/31
- Re: Supporting arbitrary file attributes, Joerg Schilling, 2002/03/31
- Re: Supporting arbitrary file attributes, Joerg Schilling, 2002/03/31
- Re: Supporting arbitrary file attributes, Joerg Schilling, 2002/03/31