On 31Aug2020 14:20, Chris Angelico <ros...@gmail.com> wrote: >On Mon, Aug 31, 2020 at 1:17 PM Cameron Simpson <c...@cskk.id.au> wrote: >> Each "source" symlink has its own inode. But if you os.stat() the >> symlink it follows the symlink and you get the inode for the "target" >> directory - two symlinks which point at the same directory will return the >> same >> inode and thus (st_dev,st_ino) in that stat result. >> >> That can be used for comparison, and you don't need to readlink or >> anything like that - let the OS do it all for you during the os.stat() >> call. > >Note that this is only the case if os.stat is called with >follow_symlinks=True, which is the default, but isn't the only way to >do things.
Maybe not, but it is the way I'm suggesting. >> >[old-Unix-guy story: Way back when, SunOS used to allow you (if >> >root) >> >to create a hard link to a directory. It's not something you did a >> >second time.] >> >> It's a well defined operation. There are some policy choices an OS can >> make about some of the side effects (how does pwd work? how you got >> there? or some underlying "real" path - this spills over into "what does >> ".." mean?), etc. But having made those choices, the idea is just fine. > >Is it well defined? It can be well defined. Probably should have phrased it that way. >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. >BTW, the pwd issue actually isn't an issue, since it really *will* be >"how you got there". You can see that with modern systems if you have >symlinks in the path, or rename a directory: [...snip...] Yeah, makes me ill. That's because these days "pwd" is usually a shell builtin with funny semantics and a cache/sanity=check against $PWD (which gets computed as you cd around, typically). And if has a -P option and friends explicitly because of this hideous stuff. Cheers, Cameron Simpson <c...@cskk.id.au> -- https://mail.python.org/mailman/listinfo/python-list