Symlinks already present
Chris Angelico
rosuav at gmail.com
Mon Aug 31 00:20:17 EDT 2020
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. And if you get stat results while you're iterating over a
directory, you don't follow symlinks.
> >[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? 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?
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:
rosuav at sikorsky:~/tmp$ mkdir -p a/b/c/d/e
rosuav at sikorsky:~/tmp$ cd a/b/c/d/e
rosuav at sikorsky:~/tmp/a/b/c/d/e$ mv ~/tmp/a/{b,q}
rosuav at sikorsky:~/tmp/a/b/c/d/e$ pwd
/home/rosuav/tmp/a/b/c/d/e
rosuav at sikorsky:~/tmp/a/b/c/d/e$ cd `pwd`
bash: cd: /home/rosuav/tmp/a/b/c/d/e: No such file or directory
rosuav at sikorsky:~/tmp/a/b/c/d/e$ ls -al
total 8
drwxr-xr-x 2 rosuav rosuav 4096 Aug 31 14:17 .
drwxr-xr-x 3 rosuav rosuav 4096 Aug 31 14:17 ..
rosuav at sikorsky:~/tmp/a/b/c/d/e$ cd ..
rosuav at sikorsky:~/tmp/a/q/c/d$ pwd
/home/rosuav/tmp/a/q/c/d
rosuav at sikorsky:~/tmp/a/q/c/d$
As soon as I try to go to the parent, it has to figure out what the
real path to that parent is. Otherwise, it's just the path that I
typed to get there - even though that might no longer be correct.
(There have been times, for instance, when I'm in a "dead" directory
and have to cd `pwd` to get back to the "real" directory with the same
name.)
The parent directory is crucially important here.
ChrisA
More information about the Python-list
mailing list