Symlinks already present

Chris Angelico rosuav at gmail.com
Mon Aug 31 03:35:12 EDT 2020


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


More information about the Python-list mailing list