Symlinks already present

[Barry Scott]

> On 31 Aug 2020, at 17:38, Richard Damon <Richard at Damon-Family.org> wrote:
> 
> 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.

I'm intrigued.

How are you adding a second path that shows this mutating ".." ?
I tried with a symlink and that did not change the ".." inode.
Do you mean that I can do this with a bind mount?

Barry


> 
> -- 
> Richard Damon
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list <https://mail.python.org/mailman/listinfo/python-list>