On 8/31/20 9:00 AM, Chris Angelico wrote: > On Mon, Aug 31, 2020 at 9:57 PM Richard Damon <rich...@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 <c...@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 -- https://mail.python.org/mailman/listinfo/python-list