Re: Chroot and ".."

[Jonathan S. Shapiro]

On Thu, 2005-10-13 at 19:04 +0200, Marcus Brinkmann wrote:
> Actually, I think that the Korn/Gansner design is the right approach
> for a good native interface.  I am not sure that it is a good
> emulation if compatibility is required.  The POSIX VFS stuff is very
> hairy, and even small differences cause a significant number of
> incompatibilities, as past experience has shown.

None of this would touch VFS at all. There is strong anecdotal evidence
that (a) this is compatible enough, and (b) those applications that it
violates were in any case broken and need to be fixed.

However, this is not the same as putting the change into actual service,
and the only way to really be sure is the hard way.

> Here is one of the potential pitfalls I see: If you adopt the
> Korn/Gansner design, I suppose that in the application (ie, in the C
> library), you keep a string that is associated with the current
> directory capability.

Thankfully, POSIX does not actually expose anywhere the fact that CWD is
really a descriptor. This leaves us free to implement CWD in a different
way that is more consistent.

The right way to implement CWD is as a pair of strings. The first is a
string of strings, each of which is a path component:

   "foo":"bar":"baz

The second is a string of directory capabilities:

   {dircap-for-foo}:{dircap-for-bar}:{dircap-for-baz}

These are manipulated in parallel in the obvious way. In EROS, we would
probably implement a CWD object for this purpose.

This approach addresses your caching concerns, and it also addresses the
problem of recovery when the directory structure is rearranged or
directories are destroyed.

> Is there a performance concern here in always looking up absolute
> paths?

Yes, but not in the proposal I have outlined.

> If one of the parent directories is renamed, you have to update the
> string in each application that has a current directory within the
> renamed directory tree, or you are in danger of looking up the wrong
> directory or not finding your original directory tree anymore.

This is true with symlinks too. It is rare enough that it is not a
problem in practice, and in the proposal I give above, the application
can become inconsistent with the directory tree but does not break as a
consequence.

> So far, so good.  The problem is that caching can introduce other
> compatibility problems, because sometimes applications want to _see_
> the new directory that was renamed into the place of an old directory.
> Again, I don't have an example, but there must be at least some.

Yes. What you are encountering is the following harsh reality:

  When you commit a bogus assumption into an architecture, you
  are going to break something when you fix it.

In this case, the bogus assumption was the strict hierarchy assumption.
The question is not "will we break something?" the question is "Given
that the assumption is bogus, how can we fix it while breaking a minimal
number of applications?"


shap