Symlinks already present

[Richard Damon]

On 8/31/20 9:00 AM, Chris Angelico wrote:
> 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

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.

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.

-- 
Richard Damon