Symlinks already present

[Chris Angelico]

On Mon, Aug 31, 2020 at 9:57 PM Richard Damon <Richard at damon-family.org> wrote:
>
> On 8/31/20 3:35 AM, Chris Angelico wrote:
> > On Mon, Aug 31, 2020 at 5:28 PM Cameron Simpson <cs at cskk.id.au> wrote:
> >>> Because of the ".." issue, it's not going to be as
> >>> symmetric as hardlinking files is. You can move a file by hardlinking
> >>> it and then unlinking the original name. If you do that with a
> >>> directory, at what point do you update its parent pointer? What
> >>> happens if you create TWO more hardlinks, and then unlink the original
> >>> name? Can you even *have* a single concept of a "real path" without it
> >>> basically just being symlinks in disguise?
> >> Shrug. Who says ".." is wired to the directory, and not the user's
> >> process context? Who says a wired to the directory ".." needs changing
> >> at any time except when its referring link count goes to 1? There are
> >> many choices here. Making those choices is a policy decision for the OS
> >> implementor, and they all have their costs and benefits.
> >>
> > Consider the situation I posed: start with one reference to the
> > directory, add two more, then remove the original. Where is its
> > parent? Is there any good way to handle that? And if you allow
> > hardlinking of directories at all, there's no reason to block this
> > particular sequence of operations. A naive reading of your description
> > is that the parent, in this situation, would remain unchanged - which
> > means the parent is some completely unrelated directory. Or, worse, it
> > could end up with a parent of itself, or a parent of its own child.
> >
> > Are you SURE it can be well-defined?
> >
> > ChrisA
>
> EVERY  reference to the .. file link has to have a full path to that
> link, either explicit with the reference of implicit via the current
> working directory. That can define what is the parent. Yes, that says
> that two references to the 'same' directory (same as in same inode, but
> different paths) will find a different value for .. in it. So the
> definition of .. can be well defined, even in the presence of multiple
> parent directories.
>

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