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

[Marcus Brinkmann]

At Thu, 9 Feb 2006 13:46:47 +0100,
Bas Wijnen <address@hidden> wrote:
> 
> 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.

They are co-equal, yes.

> 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.

"Find" will have to detect loops, yes.  There is a way to do that
(naively, by comparing device and inode numbers).

There is a similar problem with symbolic links, of course.

> 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.

I don't understand this last sentence, can you rephrase?

> 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.

Yes, but are they rare because they are not useful, or are they rare
because we have learned to avoid them (because Unix does not offer
this feature)?
 
> > > > > 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).

But there is no file system any more ;)

> 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.

This is a matter of policy, not of mechanism.
 
> > 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).

There is no file system :)

> And in fact, the backing store of the persistent system can very well be
> considered a file system as well.

Ok, you are free to call it a file system, but then we are talking
about a very different file system from what we call a file system in
Unix, or Hurd on Mach.

> We need a namespace anyway, and I think it
> makes sense to call it a filesystem.

Now you are calling the name space the file system.  At one point, I
will ask you to make a decision what you want to call a file system :)
For now, let's shift focus and look at name spaces.

There is not a single name space.  This is true even in Unix, where
you have different name spaces, one for each partition (file system)
and potentially even different name spaces per application (chroot).

The namespace is partially implemented in the application, and
partially in the directory servers.  We start with a simple setup
where every directory is implemented by its own server process
(translator).  Then we can optimize it by putting several directories
into a single server, but note that then we probably state a policy
about resolution of directory traversal into the server (if we
shortcut lookup of names like "a/b/c").

However, the actual file objects are probably implemented by a
different server.  At least conceptually there is a clear separation.
 
> > > "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. ;-)

Maybe I don't understand what you mean by private and public.  In
which namespaces are the names visible?
 
Thanks,
Marcus