Symlinks already present

[Richard Damon]

On 8/31/20 12:49 PM, Chris Angelico wrote:
> 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.
The file descriptor could remember the path used to get to it. chroot
shows that .. needs to be somewhat special, as it needs to go away for
anyone that . is their current root.
>
>> 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

I see no problem with it being a hardlink, and in fact, executables know
the name they were executed by, so directories  knowing the path isn't
that different. The key differnce between a hardlink and a symlink is
that hardlinks maintain existance, and always point to something that
exists (things know how many hardlinks refer to them). symlinks don't
reference the actual file object, but the symbolic path to it, which may
or may not actually exist, and who doesn't know such a link exists.

-- 
Richard Damon