Re: support for translators in tar

[Kalle Olavi Niemitalo]

[I already typed this once but lost power before sending.  :-(
This time, I ensured auto-save-mode is on.]

Paul Eggert <address@hidden> writes:

> What does 'ls -l' do?  Users will probably want 'tar' to do something similar.

It starts the passive translator and gets the stat data from
that.  This makes the first run of 'ls -l /dev' or even 'ls
--color /dev' very slow.

> What 'ls' switch is used to see a translator rather than to invoke it?
> What does the 'ls' output look like in that case?

There is no such switch, but there is a separate program
'showtrans'.  I can't test now, but if I read the source right,
the output of 'showtrans /etc/passwd /dev/full' would look like:

/etc/passwd
/dev/full: /hurd/null --full

This means /etc/passwd has no translator, and /dev/full has
"/hurd/null" with an argument of "--full".  These strings are
internally kept null-terminated, so they could contain spaces,
but the output of showtrans is ambiguous if they do.

There has been a lot of talk about extending 'ls' to display the
Hurd's fourth rwx permission set.  When someone eventually does
that, (s)he could also add an option for showing passive
translators.  That would be more convenient than a separate
'showtrans' program, I think.  The output could then also obey
the '--quoting-style' option.

When 'tar' saves a translator, it must also save the file or
directory underlying the translator, in case the translator wants
to access it when run.  The underlying node can be opened with
O_NOTRANS.

The tar format should be extended to support the following data
for each file, in addition to what it stores already:

1. Passive translator.

   Usage:  Command line for a program that the parent filesystem
   starts when a process looks up the file.

   Type:  List of strings.  The strings cannot contain null
   characters.

   Frequency:  Most files haven't got passive translators.

   Format:  The RPC interfaces and ext2fs (I don't know about
   ufs) keep the passive translator in argz format (see the glibc
   manual) so it could be easiest to use that format in the tar
   file too.  The ext2fs format restricts the argz to the
   filesystem block length minus two bytes, but I don't think tar
   should inherit that limitation.

   Default:  When extracting a non-Hurd archive, don't set a
   translator except implicitly via mknod or symlink.

   API:  There is S_IPTRANS for mode_t, but I think that's a bit
   late since a stat already uses the translator.  'showtrans'
   gets a Mach port to the file with file_name_lookup, reads the
   passive-translator argz with file_get_translator, and closes
   the port with mach_port_deallocate.  'settrans' uses
   file_set_translator in a similar way.

2. Fourth rwx set.

   Usage:  Read, Write and Execute permissions for processes that
   don't have any UIDs at all.  There is also a bit that says
   whether the fourth set is active.  If it is not active, then
   the "other" set is used instead.  Legacy programs that set
   permissions are expected to store 0 in the activity bit, which
   currently means "not active".  Some later version of the Hurd
   may change 0 to mean "active", so that UIDless processes
   don't get any permissions by default (since the rwx bits are
   also 000).

   Type:  3+1 bits.

   Frequency:  In principle, all files have these bits.  However,
   they will often be all zero.

   Format:  If the bits are zero, I think they needn't be saved.
   The possible future inversion of the activity bit could
   corrupt permissions of old tar files.  I think it is best to
   only design the format for now and not actually save nonzero
   values until we know for sure whether the bit will be
   inverted.

   Default:  Zero.  If it's good enough for legacy programs, it's
   good enough for legacy archives.

   API:  These mode_t bits can be read with stat and changed with
   chmod.  Constants: S_IUSEUNK, S_IUNKNOWN, S_IUNKSHIFT.  See
   <bits/stat.h> for details.

3. Author ID.

   Usage:  Another UID.  Doesn't affect any permissions.  The
   owner or root can store any value here.

   Type:  uid_t, 32 bits.

   Frequency:  All files have an author ID, but it is normally
   the same as the owner UID.

   Format:  I suppose tar could store both the number and the
   name, like with UID and GID.

   Default:  When extracting a non-Hurd archive, don't set the
   author ID; let the file system choose the default.
   (FIXME: Is this reasonable if 'tar' then does a chown?)

   API:  To read the author ID, use stat and see st_author.  To
   change it, get a Mach port to the file and call file_chauthor.

Can these be added in such a way that older tars can still read
Hurd tar archives?