Symlinks already present

[Cameron Simpson]

On 31Aug2020 14:20, Chris Angelico <rosuav at gmail.com> wrote:
>On Mon, Aug 31, 2020 at 1:17 PM Cameron Simpson <cs at 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 <cs at cskk.id.au>