Symlinks already present

[Chris Angelico]

On Tue, Sep 1, 2020 at 2:40 AM Richard Damon <Richard at damon-family.org> wrote:
>
> On 8/31/20 9:00 AM, Chris Angelico wrote:
> > That's incompatible with the normal meaning of "..", and it also
> > implies that any time you rename any directory, you have to scan all
> > of its children (recursively) to find any parent directory references
> > that need to change. I'm still not sure how this solves the problem -
> > it just pushes it to everything else, and you still have to have ".."
> > mean multiple things somehow.
> >
> > ChrisA
>
> The . and .. entries in a directory don't need to be 'real' entries
> added to the directory using up directory slots in the directory, but
> pseudo entries created by the file system when reading a directory. To
> read a directory, you need to specify it (how else do you say you want
> to read it), and the meaning of . and .. can be derived from the path
> used to read the directory.

You can open a directory (same as you open a file), and then you have
an open file descriptor. You can open something relative to something
else. And you can chroot in between those two operations, which would
mean that there is no complete path that references what you are
opening.

> And yes, this means that a given directory, reachable by multiple paths,
> may give different values for .. (or .) based on which path you came to
> it from.

That would basically violate the concept of hardlinks, which is that
they have the same content regardless of how you access them. What
you're suggesting is far better handled by symlinks.

ChrisA