bug-hurd
[Top][All Lists]
Advanced

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

Re: support for translators in tar


From: Kalle Olavi Niemitalo
Subject: Re: support for translators in tar
Date: 13 Sep 2001 01:35:13 +0300

Neal H Walfield <neal@cs.uml.edu> writes:

> > 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.
> 
> Do not forget, translators maybe stacked.

A file system can save only one passive translator for one node;
this is implicit in the file_set_translator RPC.  The original
file system saves only the passive translator that is closest to
it; that first translator is then responsible of saving the
second passive translator, etc.

Now, where does the first translator save the second passive
translator so that it will survive reboots?  It doesn't fit in
the metadata of the underlying node.  The second passive
translator must be saved as data, either in the underlying node
or in some auxiliary file.  In the first case, tar will backup or
restore the data without knowing it describes a translator.  In
the second case, the user can instruct tar to save the auxiliary
file too.  (It probably contains more data about the user-visible
file than just the translator setting, so it would have had to be
saved anyway.)

We could have these files:

  /orig: empty file with a passive translator '/hurd/ext2fs /img'

  /img: ext2fs image file.  The root directory has a passive
  translator '/hurd/null', but to tar reading /img that appears
  as just data.

When a process reads /orig, the ext2fs translator starts up,
parses the superblock of /img and offers its root directory.
That has a translator too, and the process gets a null device.
It is enough if tar saves the '/hurd/ext2fs /img' from /orig, and
the contents of /img.

Sorry if that was too verbose.

> >    Format:  If the bits are zero, I think they needn't be saved.
> 
> I disagree; they may be zero for a good reason.  

I was thinking that the new flags and other things may need a new
type of block in the tar file.  We can avoid incompatibilities
and save some space by leaving the block out whenever it contains
only values that tar -x would use by default anyway.



reply via email to

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