[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

support for translators in tar

From: Marcus Brinkmann
Subject: support for translators in tar
Date: Sun, 9 Sep 2001 22:57:47 +0200
User-agent: Mutt/1.3.20i


I want to tackle the issue of support for translators as used in the Hurd by
tar.  This is important for installation tar files (/dev/ nodes), for

For the tar maintainer: The Hurd allows to attach programs to filesystem
nodes, those programs service all filesystem accesses (inkl. stat()!).
Such running servers are active translators, and mostly transparent to the
user.  We have GNU extensions in the C library to detect them, though (but
we need _GNU_SOURCE).
The servers can be started transparently from passive translators which is
a command line string stored in a block of the filesystem and associated
with an inode.  This command line string is used to start up the actuve

It is those passive translators that should be stored and restored by tar on

Some properties of passive translators (aka translators from now on) are
shared by symlinks.  Both are stored as a string connected to an inode. 
Both can be dereferenced or not.  In fact, symlinks are implemented as
special translators in the most general case (for efficiency, filesystem
servers can use native symlink support if they want).  A symlink is by
definition a "/hurd/symlink TARGET" translator.  The program /hurd/symlink
exists and is a translator that provides the expected functionality (of
course, this program is not regularly used, and POSIX programs see the
symlink as defined by POSIX).

Now to tar.  Of course, reading and writing translators is a GNU extension.
All calls necessary to do this are part of the C library, so it is easy to
add the support (autoconf-wise).  I expect that the archive management
code is mostly the same between long symlinks and translators.

The default for symlinks is to store them, dereferencing is possible with -h
(--dereference).  For translators, I think the opposite should be true. 
Users expect translators to be transparent to normal applications.  For
example, mount points are also translators, and I expect tar to not store
the mount point settings, but the data within.

The check for a translator should be done before any other check, to avoid
starting up the server unnecessarily (any normal file i/o on the node, even
a stat(), starts up the server).  There is one complication.  Symlinks, device
files, fifos and similar are also implemented as translators.  However, I'd
expect that a symlink together with the --do-not-dereference-translators
option will not store a /hurd/symlink translator, but a symlink.  So, the
translator handling code will recognize the couple of special translators
and coerce them into archive entries compatible to traditional Unix systems.

I write all this to make sure the above is what everybody wants, and in the
hope to get some pointers into the relevant parts of the tar code.  Of
course, if the tar people (Paul?) want to do the changes, I am happy to
just assist with the Hurd specific parts and testing.  The reason I am not
just diving into the source is that the details of tar are quite complicated
(format versioning etc), and I am sure that I would spent a lot of time just
figuring out where to put the code.


`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]