Re: Perils of Config Files (was DogCows or Polymorphism in the Hurd)

[Bas Wijnen]

On Thu, Feb 09, 2006 at 12:30:38PM +0100, Marcus Brinkmann wrote:
> At Thu, 9 Feb 2006 10:28:47 +0100,
> Bas Wijnen <address@hidden> wrote:
> > I don't like hard links to directories, but of course that would be the most
> > logical equivalent of two files binding the same (directory-implementing)
> > facet.
> 
> Why don't you like them?  I would like to hear your concerns.

With two hard links, none of them is more important than the other.  That is,
there is not one "real" file, and an extra link to it.  If you're lucky, that
means a recursive search (such as find does) becomes very long because of that
(because it traverses the directory several times instead of just once).  If
you aren't lucky, there's a loop and find will never stop.

Of course there are remedies for these problems.  Find could be changed to not
go into a directory where it has been before.  But that would result in
directories coupled and arbitrary links, for example in an ls -R.  That would
make such output much less useful.

Then again, in some cases there really is not one "real" place for the thing
to be bound.  In that case, whatever you do will have these problems.  But I
think these cases are usually rare.

> > > > Anyway, find will get in trouble if it follows translators (which are
> > > > now called "facets", and are limited to types which do something to
> > > > some related node) anyway.
> > > 
> > > Translators are not called facets.  They are two quite different
> > > things.  Translators are simply object servers, preferably ones that
> > > speak the directory and/or file protocols.
> > 
> > Right, sorry about being unclear.  What I meant was that for this specific
> > case, a binding of a facet to a filename can very well be implemented as a
> > translator.  Thus the problems that find has with following translators
> > are also present when find goes "into" facets.
> 
> Ok.  I think you still have a misconception: _Everything_ is going to
> be a translator :) "Files" are objects provided by the "file"
> translator.  We want to remove the difference between files and
> translated files.

That's not a misconception, that's a difference in opinion. ;-)  I think it
would be a good idea if "normal" files are not translated (other than by their
filesystem, as is the case in the current Hurd on Mach).  The reason for this
is that without it, things like tar become a nightmare: "But I tarred the
whole directory, what do you mean `that facet doesn't include the information
you need'?"

I think it is useful to have a "raw" version of every file, for which you are
certain that it contains all information that a translator can show about it.
That is, if you copy the file to a different machine, then you get the same
result.  This should particularly also be true for translators which the
copying person didn't know existed.

> Ie, there won't be any need to create an empty file on which you
> install the translator.  Instead, you install the translator by
> linking it into a directory under a (potentially new) name.

This sounds useful, but not revolutionary.  Settrans could easily be extended
to create a file if it doesn't exit yet.

> The reason this works is that in a persistent system with a directory
> server, you don't need to create any "inode" in the "filesystem" with
> which a translator is associated.  This is because there is neither a
> filesystem nor inodes.

Of course there is a filesystem.  What you mean is that most things don't
happen there (as opposed to UNIX, where everything happens there).

And in fact, the backing store of the persistent system can very well be
considered a file system as well.  We need a namespace anyway, and I think it
makes sense to call it a filesystem.  How exactly it's implemented isn't very
relevant.  I agree with you that the backing store of a persistent system is
in some ways very much unlike a filesystem.  But in other ways it isn't.

> > "Within that program" means that this default is not valid anywhere else.
> > If I'm in bash, I need to do the explicit binding.  Of course once the
> > binding is made, it stays there until it is removed.
> 
> Then there is a difference.  In my model, the shell would use
> something like ~/.shell/cache/... to create its "private" name space.

That is one option for the "default", which is indeed private.  A public
version would be an other option, but it might not be a good idea.

I still don't think there is a difference, though. ;-)

> I am not sure this is really necessary.  Maybe it isn't, if all calls
> to "open" can be traced to the shell, which knows about its private
> bindings.  Then magic filenames that do not actually exist in the
> directory servers could be used.  In any case, this is a minor detail
> that should be resolved by what is practical to implement.

Indeed.  What is useful to know now is what limitations do (and don't) exist
for the different options.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature