Symlinks already present

[Richard Damon]

On 9/1/20 9:03 AM, Chris Angelico wrote:
> On Tue, Sep 1, 2020 at 10:57 PM Richard Damon <Richard at damon-family.org> wrote:
>> On 8/31/20 6:05 PM, Chris Angelico wrote:
>>> On Tue, Sep 1, 2020 at 5:08 AM Richard Damon <Richard at damon-family.org> wrote:
>>>> 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.
>>> But my point is that there might not actually *be* a valid path that
>>> gets you to a file descriptor. It can't remember something that
>>> doesn't exist. (And it's pretty impractical to do that even if it
>>> does.)
>> Remember, we are talking about a hypothetical OS that handles hardlinks
>> to directories, and defines that .. will point to the parent used to
>> come to it, NOT just having current *NIX allowing hardlinks to
>> directories with no remediation of the issues cause.
> Yes. I'm assuming that you can define things any way you like.
>
>> One result of the definition, is that when you open a file/directory, if
>> it might be a directory, the system WILL need to remember the path to it
>> (so as to provide a value for ..) and that memory will provide a
>> 'reference' for the directories so they can't go away (just like an
>> unlinked file stays around will someone has it open). The normal way to
>> get a file descriptor starts from a path, so the path had to exist in
>> the first place, and since we are assuming that to get .., it keep a
>> reference to that path, it can't truly go away.
>>
> But as I've pointed out, you don't always *have* a valid path. File
> descriptors can be passed from process to process (most commonly by
> being retained when you fork and not closed when you exec, but there
> are other ways too, eg sockets), so even though starting with a path
> is the most common, it isn't the only way, and you could easily have
> an FD with no associated path, and then read it to find out what ".."
> is.
>
> Also, even if all that could be solved, I don't like the idea that
> reading the same directory from two different sources leads to
> different results. Is it really the same directory if reading it in
> different ways gives different results?
>
> ChrisA

But when you pass the file descriptors to another process, the OS knows
this, so the data that was pointed by the descriptor (which is where you
would keep it anyway) still has it.  There is no normal way that I know
of from user land to get to a directory except from a path or at least
an object that could have remembered a path. For a FD, that FD started
with a path, so it could still remember it.

Part of your issue is likely that you are used to thinking of the file
system as a pure tree, and *nix likes to do that too. Once you accept
hard links to directories as 'normal', suddenly the meaning of .. gets
funny, as there is not a unique parent, but getting the parent as you
got there could be useful for recursive file system searches (which will
need protection from getting stuck in a loop).

My research says that Unix System V allowed them, but restricted them to
super users, to avoid the bigger problems with them. I don't know how it
handle the issue of ..

-- 
Richard Damon