Symlinks already present

[Richard Damon]

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.

-- 
Richard Damon